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ABSTRACT 

Traditionally, the design and implementation of a 
conventional database system begins with the choice of a 
data model followed by the specification of a modelebased 
data language, Thus, the database system is restricted to a 
single data model and a specific data language, An 
alternative to this traditional approach to database-system 
development is the multi-lingual database system (MLDS), 
This alternative approach affords the user the ability to 
access and ^anage a large collection of databases, via 
several data models and their corresponding data languages, 
without the aforementioned restriction, 

In this thesis, we present a methodology for supporting 
network (CODASYL) database management on the MLDS, 
Specifically, we design an interface which translates 
CODASYL-DML statements into ABDL requests, We describe the 
data structures, the control mechanisms, and the functions/ 


procedures necessary to implement such a system, 
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I. IXNIBODUCIIQU 


A, MOTIVATION 

During the past two decades, the design and 
implementation of database systems has followed a rather 
predictable path, The sequence of events in tne typical 
approach has been to decide on 3a data model, specify a 
modelebased language, and ultimately, develop a system for 
controlling and executing the tranSactions written in the 
data language, This approach to database system development 
has resulted tn an abundance of homogeneous database 
systems each of which restricts the user to a single data 
model and a Specific modelebased data manipulation language, 
Some examples of systems developed using this approacn 
include IBM%s Information Management System (IMS) which 
supports only the hierarchical data model and Data Language 
I (DL/I), Sperry Univac’s DMS-1100 which supports just the 
network data model and the CODASYL Data Manipulation 
Language, and IBM*'s SGL/Data System which supports solely 
the relational data model and the Structured Englisn Query 
Language (SQL), 

An unconventional approach to the problem of database 
management system development, referred to as the Multi- 
lingual Database System (MLDS) (Ref, 41], eliminates the 


restrictions mentioned above, The MLDS would give the user 
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the ability to access and manage a large collection of 
databases, using several data models and their corresponding 
data languages, The design goal of the MLDS project is tne 
development of a system tnat is accessible via a 
hierarchical/OL/I interface, a relational/SQUL interface, a 
network/CODASYL interface, and an entity-relationship/Daplex 
interface, Such a system would function as if it were a 
heterogeneous collection of database systems instead of a 
Single model, single language system, 

Some of the advantages of a MLDS are the reuseability of 
database transactions developed on a conventional system, 
economy and effectiveness of hardware upgrades (since we now 
upgrade just one System instead of a number of different 
systems), and its ability to Support a variety of databases 
built around any of the well-known data models, Thus, there 
is ample motivation for developing such a system as the 


MLDS, 


B, THE SYSTEM ORGANIZATION 

In order to realize the above capabilities, the MLDS 
must be supported by an underlying database system that is 
both fast, efficient, and effective. If these criterion are 
not met, then the interfaces being developed for the MLDS 
may be rendered useless, Hence, it is important that tne 
Kernel data mode] and kernel data language (the underlying 
model and language for the system) be supported by a highs 


performance and highe+cavacity database system, Currently, 
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the attribute=based data model and attribute-=based data 
language are the underlying model and language of a system 
which is referred to as the ‘ultisbackend Database System 
(MBDS). In this section, we provide an overview of both tne 
MLOS and tne MBDS to enhance the readers understanding of 
the entire Multi-Lingual Database System, 
l. Ine Multi-Lingual Database Systeo 

Figure 1 illustrates the complete structure of the 
multi=lingual database system, The user interacts with the 
system through the language interface layer (LIL), using a 
chosen user data model (UDM) to issue transactions written 
in a corresponding modelebased user data language (UDL), 
The LIL routes the user transactions to the kernel maoping 
system (KMS). The KMS then performs one of two possible 
tasks, It either transforms a UDMebased database definition 
to an equivalent database definition based on the kernel 
data model (KDM); or, when the user specifies that a UDL 
transaction is to be executed, it translates the UDL 
transaction into an equivalent transaction in the kernel 
data language (KDL), 

The first task is performed in the following way, 
The KMS forwards the KDM data definition to the kernel 
controller (KC), The KC then sends the KDM database 
definition to the kernel database system (KDS), when the 
KDS is finished with processing the KDM database definition, 
it informs the KC, The KC then notifies the user, via the 


LIL, that the database definition has been processed and 
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that the loading of the database records may begin, The 
second task is performed in a similar fashion, The KMS 
sends the transactions to the KC which in turn, sends the 
transactions to the KDS for execution, unce the execution 
is complete, the KDS sends the results in the KD" form back 
to the KC, The KC routes the results to the Kernel 
formatting system (KFS), The KFS reformats the results from 
the KDN form to the UDM form, The KFS then displays tne 


results in the correct UDM form via the LIL, 


UDM KMS 


LIL KG RD 


Un 


zn $ 


CONI : User Data Model 


UDL : User Data Language 

LIL : Language Interface Laver 
KMS : Kernel Mapping System 
KC : Kernel Controller 

KRES : Kernel Formatting Svstem 


KDM : kernel Data Model 
KDL : Kernel Data Language 
KDS : Kernel Database System 


Figure i: The MultieLingual Database System (MLDS), 


The four modules, LIL, KMS, KC, and KFS, are 


collectively Known as the language ¿nteríace. Four 
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interfaces with similar modules are required for the four 
interfacing user models and languages (1.6., relational/SQL, 
hierarchical/DL/I, network/CODASYL+=DML, and entíty» 
relationship/Daplex) of the MLDS, 

2. Ihe Bulti-Backend Database SysLran 

The multi-backend database system (MBDS) was 
designed to overcome the performance problems and uparade 
problems associated with the traditional approach to 
database system design, This goal was realized through the 
utilization of multiple backends connected in a parallel 
fashion, Tne backends have identical hardware, replicated 
software, and their own disk systems, In the multi-backend 
configuration, there is a backend Controller, whicn is 
responsible for supervising the execution of database 
transactions and for interfacing with the nosts and users, 
The backends perform the database operations with the 
database stored on the disk system of the backends, The 
controller and backends are connected by a communications 
DUS. Users access the system through either the hosts or 
the controller directly (see Figure 2), 

Performance gains are realized by increasing the 
number of backends, If the size of the database and tne 
size of the responses to the transactions remain constant, 
then MBDS produces a reciprocal decrease in the response 
times for the user transactions when the number of backends 
is increased, On the other hand, if the number of backends 


is increased proportionally with the increase in database 


Br 


size and transaction responses, then the MBDS produces 
invariant response times for the same transactions, For a 
more detailed discussion of MBDS tne reader is referred to 


(Refs, 2 and 3], 







| Backend Store 1 
| 





Backend 


Processor 1 











Backend 


Processor 2 









Backend 
Controller 










Backend 


|! 
I 
B 
T Processor M 
| 


Communications 
Bus 


Figure 2: The Multi-backend Database System (MBDS), 


In this thesis, we investigate the design of a 
network (CODASYL) interface for the MLDS, Banerjee [Ref, 4), 
provided an initial design for such an interface, we are 
extending hís work and adapting it to support the 
requirements of the MLDS, In particular, we present a 
specification for the kernel mapping system (KMS) that will 


be used in the network interface, We also ocorovide an 
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implementation strategy for the kernel controller (KC), The 
other two modules, the LIL and the KFS are nearly the same 
in structure as those already implemented for the DL/I and 
SQL interfaces, and thus, they will not be discussed in 
detail in this thesis, The reader is referred to [Refs, 5 
and 6) for further details on tne design of these modules, 
Throughout this thesis, we will make extensive use 
of the SupplierseandeParts sample database used by Date 
(Ref, 71 for illustration of our work, The data structure 
diagram for this network is shown in Figure 3, There are 
supplier records (S), parts records (P), and shipments (SP) 
records, The sets of the database are subplierseshipments 


(SeSP) and partseshipments (PSP), 


S p 
¿oro or rr 02 A y os dd 
i suppliers | | parts | 
E "X - 
( SeSP ) ( PSSP-) 





¿aro o hr rr doo oa 


| shipments | 


a 
Figure 3: Data Structure Diagram of the Sample 
SupplierseandeParts Database, 
In Chapter 2, we provide a description of both the 
network (CODASYL) data model and the attributeebased model, 
as well as, their associated data languages, In Chapter 3, 


a methodology for mapping a network (CODASYL) database into 
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an attribute-based database is presented, Chapter 4 is 
aedicated to explaining the data manipulation language 
translations, And, in Chapter 5, we provide implementation 
condiderations for both the KMS and the KC, Finally, in 
Chapter 6, we make our conclusions about the proposed 


design. 
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II. IHE QATA LODELS 


The choice of a Kernel data model and a corresponding 
kernel data language is of vital importance in developing a 
multi-lingual database system, The kernel data model and 
the kernel] data language must be capable of supporting all 
the necessary data model transformations and data language 
translations required by the MLDS language interfaces, 

It is our intention in this chapter to provide a summary 
description of the data models related to the network 
(CODASYL) interface, namely the CODASYL data model and the 
attributeepased data model, A conceptual view of both 
models will be presented along with a brief discussion of 


the data manipulation languages associated with each model, 


A. THE CODASYL DATA MODEL 

In general, the network (CODASYL) data model is based on 
the concept of directed graphs., The nodes of the graphs 
usually represent entity types whieh are described py 
records, while the arcs of the graphs correspond to 
relationship types that are represented as connections 
between records, The CODASYL (Conference on Data System 
Languages) data model is referred to by Tsichritzis and 
Lochovsky (Ref, 83pp, 119-132] as the most comprehensive 


specification of a network data model that exísts, Thus, the 
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reason for choosing the CODASYL data model and its data 
manipulation language for the network interface of the MLDS, 
1, & Casceatual Ulew of tha dodal 

CODASYL databases are networks of record types and 
set types, where records and sets are tne entities which 
describe the databases, A record type in a CODASYL database 
is defined in (Ref, 4) as a collection of hierarchically 
related data item names or field names, These field names 
are specified in a schema declaration (template) for that 
record type, A r&cord is any occurrence of a record type and 
has specific values assigned to the data items named in the 
schema declarations, This implies that a record type is 
Simply a generic name for all of the records that are 
described by the same template, 

Set types in d CODASYL database indicate 
relationships between record types, They consist of a 
single record type called the gwaez record type, and one or 
more record types called the menbaz record types, Thus, a 
set type expresses explicit associations between different 
record types in the database, This characteristic makes it 
possible for a designer to model a large variety of real 
world database management problems involving diverse record 
types, Of special importance here is the fact that the 
owner record type of a set type is prohibited from being a 
member of the same set type, 

Set types have occurrences just as record types do, 


Each occurrence of a set type has one occurrence of the 
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owner record type and Zero or more occurrences of each of 
its member record types, The prohibition here is tnat a 
record occurrence cannot be present in two different 
occurrences of the same set type, This qualification 
emphasizes the pairwise disjointness of set occurrences of a 
given set type, Figure 4 gives an example of a set 
occurrence for the set type SeSP of our sample database, 

As can be seen from the example, the CODASYL data 
model makes the design of a database quite simple, However, 
keeping track of all of the relationshios can be 
considerably involved, Thus, one of our primary concerns in 
the desian of a CODASYL language interface for the MLDS is 


to preserve these relationships without the complexity, 


S (an owner record occurrence) 


¿nor narrar RARA + 


| 82 | Jones | 10 | Paris | 


¿aora r rra 


(a set occurrence) 
(SeSP) 


(two member record occurrences) 
SP SP 


¿ercer rro nono ¿oo rr rar AAA 


1 52 1 PL | 300 | | S2 | P2 | 400 | 


JAdASXZ I ZZ I ILRZZ > forro rr AAA 


Figure 4: A CODASYL Set Occurrence, 


2, iba Data H4aninulation Language (CODASXIL-DEÁL) 
CODASYLeDML is a procedural data languade, The user 
of a CODASYL database writes his programs in a general 


purpose language that hosts the GCODASYL+-DML, In general, 
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most operations in a CODASYL database are carried out by 
"navigating" through set occurrences, The starting point 
for this navigation is usually the current record of the run 
unit, The run unit is the application program (transaction) 
being executed, A full explanation of currency will be 
provided later in the thesis, Other OML operations can be 
based on the current record occurrence of a set type or 
record type, 

CONASYL=DML has several primary operations which 
support the primary database operations of retrieval, 
insertion, deletion, and modification (uodatina existing 
records), Different implementations provide varying 
collections of these operations, but we will concentrate our 
discussion on the basic ones, 

> 

The cornerstone of the CODASYLeDML is the FIND | 
statement, This statement is used to establish the currency 
of tne run unit, and optionally used to establish the 
currency of the set type and the record type, The general 


format of the FIND statement is 
FIND recordeselection-expression I ], 


where the square brackets contain optional expressions for 
the suppression of updates to the currency indicators, In 
other words, we may suppress the updating of the currency 
for a record type, a set type, or both, The recorde 


selectioneexpression has several different forms each 
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designed to access a particular record in three different 
ways, either outeofetheeblue without reference to a 
previously accessed record; relative to a previously 
accessed record; or by repetition. The other DML statements 
are somewhat less extravaaant, 

inr NOR Fed tenent in CODASYLeDML complements the 
FIND statement, Once a record is found, the GET statement 
places the record in the transaction’s working area for 
access by tne transaction, There are two basic formats for 
the GET statement, They include GET record.type, which 
gives the transaction access to the entire record, and GET 
items IN record.tyre, which gives access to only requested 
data items in the record type, 

The STORE statement is used to place a new record 
occurrence into the database, The programmer must build up 
an image of the record prior to the STORE request using 
assignment statements which are a part of the host language 
in which the CODASYL=DML is embedded, Once the record image 
has been created, then the proper set occurrence for the 
record must be selected by the database management system, 

The set occurrence in which the new record is stored 
is determined by the SET SELECTION clause specified in the 
schema definition for the object database, The three 
options available ares: BY APPLICATION, which means that tne 
application program (transaction) is responsible for 
selecting the correct occurrences BY VALUE, wnich means the 


system selects the proper occurrence based on data item 
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values specific to the owner of the Set occurrence desired; 
and, BY STRUCTURAL, which means that tne system selects an 
occurrence by locating the owner record with a specific item 
value equal to the value of that same item ín tne record 
being stored, The restriction on the last two options is 
that the data items being used must nave been specified with 
DUPLICATES NOT ALLOWED in the schema definition, A detailed 
discussion of syntax for the CODASYLeDML is presented later 
in the thesis, 

If the user transaction desires to manually insert 
records into the database, two requirements exist. First, 
the schema definition must include tne INSERTION IS MANUAL 
clause in the set desciption for this particular member 
record. Then the CONNECT statement is used, instead of the 
STORE statement, for insertion of the record into the 
database, The record to be inserted is tne current record 
of the run unit, The set occurrence in which the record is 
inserted is determined in the same way as the STORE 
statement, 

There is also a statement in tne CODASYL=-DML  whích 
performs the opposite operation, namely, the manual removal 
of a record occurrence from a set, The DISCONNECT statement 
performs this operation, It disconnects the current record 
of the run unit from the occurrence of the specified set 
that contains the record, The record occurrence still 
resides in the database, but it is no longer a member of the 


specified set, There is a qualification involved with this 
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statement, however, The record to be disconnected must have 
a RETENTION clause of OPTIONAL in tne member descipbtion for 
the set type definition ín the schema, 

In order to delete records from a CODASYL database, 
the ERASE statement is used. There are four basic options 
to this statement; however, two of them are very complex and 
marginally useful, so they will not be discussed in tnis 
thesis, The simplest of the two we will deal with is tne 
ERASE without the ALL option, This statement causes the 
current record of the run unit to be deleted from the 
database if, and only if, it is anak the owner of a non-empty 
set, If it is the owner of a non-empty set, the erase 
fails. 

The ERASE ALL option is a little less useful 
according to Olle (Ref, 9], This statement causes the 
current record of the run unit to be deleted whether or not 
it is the owner of Aa nonsempty set, Additionally, this 
option causes each member record of the set to be deleted, 
and if they too are owners of non-empty sets, their members 
are deleted, This action continues al] the way down the 
hierarchy, As one can see, an entire database could be 
destroyed if the user is not careful when using this option, 

The final statement to be covered in this thesis is 
the MODIFY statement, It is used to modify values of data 
items in a record occurrence, This includes modifying all 
data items or any subset of the data items in the record 


type, It may also be used to change the membership of a 
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record occurrence from one set occurrence to another, as 
long as, they are of the same set type, Thus, we have our 


basic working set of DML statements. 


B. THE ATTRIBUTE=BASED DATA MODEL 

Tne attributeebased data model was originally described 
by Hsiao [Ref, 10), It is a very simple but powerful data 
model capable of representing many other deta models without 
loss of information, It is this simplicity and universality 
that makes the attribute=based model tne ideal choice as the 
kernel data model for the MLDS, and the attribute=based data 
language (ABOL) as the kernel language for the system, 

1, à Cabncantual View of tha Yodel 

The attributeebased data model is based on the 
notions of attributes, and values for these attributes, An 
attripute and its associated value is therefore referred to 
as an attribnuteevalue pair or keyword. These attributes 
value pairs are formed from a Cartesian product of the 
attribute names and the domains of the values for the 
attributes, Using this approach, any logical concept can be 
represented by the attríbuteebased model, 

A zecozd , in the attríbuteebased model represents a 
logical concept, In order to specify the concept 
thoroughly, keywords must be formed, A record then, is 
simply a concatenation of the resultant keywords, such tnat 
no two Keywords in the record have the same attribute, 


Additionally, the model allows for the inclusion of textual 
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information, called the record body , in tne form of a, 
possibly empty, string of characters describing the record 
Or concept, The record body ids not used for search 
purposes, Figure 5 gives the format of an attrinute-based 
record, 

(<attributel,valuet>, +... » 


«attributen,valuen», 
( text )) 


Figure 51 An Attribute-Based Record 


The angled brackets, <,>, are used to enclose a keyword 
where the attribute is first followed by & comma and then 
the value of the attribute, The record body íis then set 
apart by curly brackets,  (,), Tne record itself is 
identified by enclosure within parentheses, AS can be seen 
from the above, this is quite a simple way of representing 
information, 

In order to access the database, the attributeebpased 
model employs an entity called predicates, A keyword 
predicate, or simply ozadicata , is a triple of the form 
(attribute, relational operator, value), These predicates 
are then combined in disjunctive normal form to produce a 
Query of the database, In order to satisfy a predicate, the 
attribute of a keyword in a record must be identical to the 
attribute in the predicate, Also, the relation specified by 
the relational operator of the predicate must hold between 


the value of the predicate, and the value of the keyword, A 
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record satisfies a query if all predicates of the query are 
satisfied by certain keywords of tne record, A query of two 


predicates 


(TYPE = S) and (SNO = S4) 


would be satisfied py any record of TYPE S (Supplier type) 
whose SNO (supplier number) is S4, and it would nave the 
form, 

C<attributel ,vavel>, «eee ,<TYPE,S>, see ? 

<SNO,S4>, eee ,cattributen,valuen>,{text)), 

2. Iba &ttiribute-Gased Data Language (ABBL) 
The ABDL as defined by Banerjee, Hsiao, and Kerr 

(Ref, 11) was originally developed for use with the Database 
Computer (DBC), This language is the kernel language used 
in the MLDS, Tne ABDL supports the five primary database 
operations, INSERT, DELETE, UPDATE, RETRIEVE, and RETRIEVE@ 
COMMON, Those of use to us in this portion of the MLDS work 
however, are INSERT, DELETE, UPDATE, and RETRIEVE, A user 
of this language issues either a request or a transaction, 
A cseguast in the ABDL consists of a primary operation with a 
qualification, The gualification specifies the portion of 
the database that is to be operated on, When two or more 
requests are grouped together and executed sequentially, we 
have a traasaction in the ABDL, There are four types of 


requests, corresponding to the four primary database 
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operations listed above, They are referred to by the 
same names, 

Records are inserted into the database with an 
INSERT request, The qualification for this request is a 
list of keywords and a record body, Records are removed 
from the database by a DELETE request, The qualification 
for this request is à query. 

when records in the database are to be modified, the 
UPDATE request is utilized, There are two parts to the 
qualification for this request, They are the query and 
modifier, The query specifies the records to be modified 
while the modifier specifies how tne records are to pe 
modified, 

The final request to be mentioned here is tne 
RETRIEVE request, As its name implies, it retrieves records 
from the database, The qualification for this request 
consists of a query, a targetelist, and an optional by= 
clause, The query specifies the records to be retrieved, 
The targetelist contains the output attributes whose values 
are required by the request, or it may contain an agaqregate 
operation, i1,e,, AVG, COUNT, SUM, MIN, MAX, on one or more 
output attribute values, The by=clause is optional and is 
used to group records when an aggregate operation is 
specified, 

As indicated, ABDL consists of Some very simple 
database operations, These operations, nevertheless, are 


capable of supporting Complex and Comprehensive 
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transactions, Thus, ABDL meets the requirement of capturing 
all of the primary operations of a database system, and is 
quite useful for our purposes, Figure 6 shows examples of 


the four primary ABDL requests, 


INSERTC<TYPFE,SP>,<SNO,S2>,<PNO,P1>,<QTY,390>, {sample}) 
DELETECCTYPE = S) and (SNO = S4)) 
UPDATECCTYPE = SP) and (PNO z P1))(OTY = QTY + 100) 


RETRIEVECCTYPE x P) and (PNAME s Nut)) 


Figure 63: Sample ABDL Requests, 
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IJI. WABRING NETWORK CCODASXL) DAIZÀ IQ AIIRIBUIE-BASEQ QATA 


Using a modification of a procedure originally outlined 
by Banerjee (Ref, 3 4), the transformation of network data 
into attribute-based data becomes a relatively simple task, 
The data must be transformed into records wnich consist of a 
set of variableelengqtn attributeevalue pairs and a record 
body, The attribute=value pairs may represent the type, 
quantity, or characteristic of the value, and the record 
body is as described in the previous chapter, Additionally, 
all attributes in the attributeebased records are distinct, 
for logical reasons. 

The key aspect of the mapping process is the retention 
of the CODASYL notions of records and sets (the linkages 
among records), we emphasize that the CODASYL notions of 


records and sets are nook the same as the attribute=based 





te arte 





notions of records and sets, Thus, the mapping algorithm 


AAA ë å oooi 








presented nerein uses attributeepased constructs (or 
notions) to implement the CODASYL notions, In the followina 
sections, we present the various entities which must be 
mapped, their corresponding attribute-based equivalent, and 
an example of the mapping process using our sample database, 
It should be clear after this description, that the CODASYL 


notions of records and their relationships are indeed 


—— — 


eng Apost A AU a t 


preserved in the attributeebased system, 
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A, THE REPRESENTATION OF A CODASYL RECORD 

A CODASYL record type is Structured as a hierarchical 
confiauration of data items such as depicted in Figure 7(a), 
where Ri is the record name, and A, 8, C, D, E, and F 
represent data item names, Figure 7(b) snows an occurrence 
of record Ri, Notice that only the values of tne data items 
are present in tne CODASYL record., In the attributeepased 
system, both the dataelLltemename and its value are stored in 


the record, 


Record Ri Record Ri 
tt d+ 
O1 A i aQievalue | 
01 B | bOi1.velue | 
02 C tl co2,.value | 
02 D | dO2.value | 
03 E | eO3.value | 
02 A | 802.valu*$ | 
01 F | fO0i.value | 
$$ AA AAA e + 

(a) (b) 


Figure 7: Hierarchical Structure of a CODASYL Record, 


Thus, in order to capture the CODASYL information, keywords 
must be created for each of the elementary data items 
included in the CODASYL record, These dataeitem keywords 


should be of the form 


« data,ítem,name,data.item.value > 


where the datawitemename 1s qualified by data-itemenames at 
a higher level if it is not unique, Figure 8 shows the data 


item representation for tne CODASYL record of Figure 7, 


32 


Cs O ANA LU > 
« C,c.value > 
« E,e.value » 
« F,f.value » 


Figure 83 Attriíbute-Based Representation of 
CODASYL Data Items, 

The dots at the beginning of the record and the dots at the 
end of the record indicate that there are additional 
keywords generated for the record in order to preserve the 
CODASYL record information, These additional Keywords are 
explained as follows, 

Each record occurrence in a CODASYL database must also 
belong to a particular type, This implies that a keyword 
indicating record type must also be included in the 


attributeebased record, Its format is 
< TYPE,record.type > 


where TYPE is a literal, 





Finally, each record occurrence of a CODASYL database 


nas a database key (or address) generated for it, Thus, 


2 


there is a requirement for representation of this value as 





well in the attribute-pased record, Tne following form is 


used for this keyword, where DBKEY is a literal, 


8 po 


«| DBKEY,database.key > 
l 5 


p 


a 
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So, in representing record information, we have the need 
for three mandatory keyword types, namely, dataiitem name, 


with or without qualification, TYPE, and DBKEY, 


B, THE REPRESENTATION OF CODASYL SETS 

In order for the attribute-based record to be complete, 
it must also include {information related to CODASYL set 
membership, and set ordering, Since occurrences of set 
types are pairwise disjoint, then each member record 
occurrence belonging to a set occurrence is also identified 


by its owner record occurrence, This means that we can 


express set membersnip by inclusion of the keyword 
« MEMBER,set,.type,owner,database,key » 


for each set occurrence in which the record i85 a member, 


Finally, tne logical position of a record occurrence 





within a set occurrence is often useful, Thus, ordering of 


member recore occurrences within a set occurrence is 


expressed by inclusion of the Keyword 
< POSITION,set.type,sequenceenumber > 


in the attributeebased record for each set in which the 


~ 


record is a member record, 


Therefore, in representing set information, we have the 
need for two keyword types, those representing member 
records, and those representing membererecord positions 


within sets, 
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C. A COMPLETE DATA@MAPPING EXAMPLE 

As previously mentioned, by utilizing the Above 
transformation scheme, we can take an existing CODASYL 
database and transform it into an attributeebased database 
without any loss of information related to tne CODASYL 
records and sets (1,@., record relationships), The 
transformation should therefore result in records of the 


form shown in Figure 9, 


(< TYPE,record,type »,« DBKEY,database.kevy >, 
< datawiteminamei,datawitem.valuel >, 

e 

a 

e 


< data..item_namen, data. item. valuen >, 

< MEMBER, set.typel, owner databasenkeyi >, 
0 
9 


< MEMBER,set,typep,owner,databasSe.keyp >, 
< POSITION, set..typeli,sequence.number >, 
0 


< POSITION, set.typep,sequence.number > 
textual information )) 


im 


Figure 9: An Example of a Transformed 
CODASYL Record, 
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SCHEMA NAME IS SUPPLIERS.AND.PARTS, 
RECORD NAME IS Sj 
DUPLICATES ARE NOT ALLOWED FOR SNO, 


SNO ; TYPE IS CHARACTER 5, 
SNAME ; TYPE IS CHARACTER 20, 
STATUS ; TYPE IS FIXED 20, 
CITY  ; TYPE IS CHARACTER 15, 


RECORD NAME IS P; 
DUPLICATES ARE NOT ALLOWED FOR PNO, 


pro ; TYPE IS CHARACTER 6, 

PNAME 3; TYPE IS CHARACTER 20, 
COLOR +; TYPE IS CHARACTER $6, 

WEIGHT 3 TYPE IS FIXED 4, 

CITY  ; TYPE IS CHARACTER 15, 


RECORD NAME IS SP} 
DUPLICATES ARE NOT ALLOWED FOR SNO, PNO, 


SNO ; TYPE IS CHARACTER 5, 
PNO : TYPE IS CHARACTER 6, 
QTY : TYPE IS FIXED 5, 


SET NAME IS S.SP; 

OWNER IS S; 
ORDER IS SORTED BY DEFINED KEYS 
DUPLICATES ARE NOT ALLOWED, 

MEMBER IS SP}? 
INSERTION IS AUTOMATIC 
RETENTION IS FIXED; 
KEY IS ASCENDING PNO IN SP} 
SET SELECTION IS RY VALUE OF SNO IN S, 


SET NAME IS P.SP; 

OWNER IS Pj 
ORDER IS SORTED BY DEFINED KEYS 
DUPLICATES ARE NOT ALLOWED, 

MEMBER IS SPP 
INSERTION IS AUTOMATIC 
RETENTION IS FIXED; 
KEY IS ASCENDING SNO IN SP} 
SET SELECTION IS BY VALUE OF PNO IN P, 


Figure 103 Schema for the Suppliers=and=Parts 
Database, 


In order to demonstrate the transformation process 
further, Figure 10 above provides tne schema definition for 


our sample Supplierseand=Parts database, Using this schema 
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definition, the CODASYL record occurrences of Figure 11 are 


transformed into the attributeebased records of Figure 12, 


S 

peor rr rr se + 

| S2 | Jones | 10 | Paris | 

¿Dor rr + 

p 
ALRLAZZAZZZILLLLZZLZLLZZLIZZIZINR 
| Pi | Nut | Red | 12 | London | 
¢ SSeS See Fe See Seen see Ga @+ 
SP 


¿forera rro Fae + 


I S2 i Pt | 300 | 


¿errar ss e > 


Fíaure 11: Sample Record Occurrences from the 
Supplierseand=Parts Database, 


(<TYPE,S>,<DBKEY, na 
<SNO,S2>, <SNAME, Jones>, 
<STATUS, 10>, <CITY, Paris», 

( Sample supplier record )) 

(<TYPE,P>, <DBKEY, 2>, 
«PNO,P1»,«PNAME,Nut», 
«COLOR, Red», «WEIGHT, 12», 
«CITY, or 
{ Sample parts record )) 


(«TYPE, SP», «DRKEY, 3>, 
<SNO,S2>,<PNO,Pi>d, 
€«3TY., 3009, — 

/ «MEMBER, SSP, UC SS 
<MEMBER,P.SP,2>, 

| <POSITION,S.SP,1>, 
.<<POSITION,P.SP,1>, 
( Sample SP record where the record 

belongs to two different sets )) 


/ 


Figure 123 AttributeeBased Equivalent of Record 
Occurrences in Figure 11, 
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IV. MAREING CODASGXL-DEL SIALERENUIS ZO ABDL REQUESTS 


Having demonstrated how network databases can be 
successfully transformed into attribute-based databases, we 
are now ready to examine the mapping of network data 
manipulation statements into ABDL requests, As mentioned in 
Chapter 2, the CODASYL data manipulation language will be 
used for the MLDS network interface, It should be noted 
here though, that only a subset of al] the available DML 
statements will be used in the MLDS network interface, 
Specifically, the following CODASYL statements will be 
incorporated in this stage of the project: FIND, GET, STORE, 
CONNECT, DISCONNECT, ERASE, and MODIFY, O£ these, only the 
useful formats were considered for the MLDS, It should be 
further noted that the syntax for tnese various statements 
was derived from the syntax presented by Date, Olle, and the 
original CODASYL report (Refs. 7, 9, and 12), respectively, 

In this section we discuss each of the above statements 
and their associated mapping process, Prior to describing 
the mapping, however, we first explain the notion of 
currency in a CODASYL database, and introduce the data 
structures that are necessary to carry out the mapping 
process, Tne Appendix, the KMS (Kernel Mapping System) 


specification, gives a detailed look at the mapping process 
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and the specific algorithms applied to accomplish the 


language translations, 


A. THE NOTION OF CURRENCY 

In general, the above data manipulation statements can 
be grouped into two categories, data retrieval statements 
and data updating statements, However, the common thread 
between the two groups, as well as, tne individual 
functionality of each statement, depends quite heavily on 
the notion of Gursency among the records and sets of the 
CODASYL database, 

The concept of currency in a CODASYL database can pe 
compared to the well known concept of current position in a 
file, The idea here is that for each application program 
being run on the system, a table of "currency indicators" is 
maintained, In general, the currency indicator is an object 
whose value is a database key. It serves as a "cursor" 
which points to either a record or a set under consideration 
by the application program, Database keys are values 
generated by the database management system that uniquely 
identify each individual record in the database, 

Tne currency indicator table for a given application 
program (or run unit) identifies the record occurrence "most 
recently accessed" by the run unit for each of the 
following: each type of record, each type of set, "any type" 
of record, and each type of realm (Realm is a CODASYL 


concept that will not be considered in this thesis.) "Any 
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type" of record refers to the most recently accessed record 
occurrence, no matter what its type 15, This record is 
appropriately called, the current of tba. cua unit , and 15 
the most important currency of all. Additionally, the 
Gucreaak af the seat tube may be either an owner record or a 


member record, whichever was accessed most recently, 


B, DATA STRUCTURES NECESSARY FOR ACCURATE TRANSLATION 
1, Zbe Currency lodicatoz Tabla (CLIQ) 

A currency indicator table (CIT) 1s created for each 
application program that is run using the MLDS network 
interface, These tables are dynamic in nature, They are 
instantiated upon the first call to the database system, and 
are updated as subsequent CODASYL®DML calls are made to the 
database system, 

CIT 
RUN. UNIT 
record.type 


database key 


record.type(i) 
database, Key 


set.type(i) 
boolean (is record an owner record) 
record, type 
database,,key 
member, record, type 
owner,record.type 
owner database, key 


Figure 133 Information Contained ín the CIT, 


The CIT contains an entry for the current of run 


unit, the current of record, type tor each record..type in the 
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database, and the current of set.type for each set.type in 
the database, Each entry in the CIT snould contain at least 
the information shown in Fiaure 13 as suggested by Meyer 
(Ref, 13], 

2. Tha Sequest Butter (BR) 

When mapping the CODASYL+*=DML statements to ABDL 
requests, there are one-to-=many correspondences between tne 
two types of statements, Thus, for each CODASYL=DML 
statement, several ABDL requests may have to pe generated to 
assemble the necessary information for accurate execution of 
the translated GCODASYL-=DML statement, In other words, a 
series of ABDL requests may be generated for each  CODASYLe 
DML statement, Some of tne requests are initially 
incomplete, however, and require information returned py 
previous RETRIEVE requests which are a part of that 
statements translation, This implies the need for storage 
of intermediate information for the requests, 

The request buffer (RB) acts as that storage 
mechanism for information returned by what we term, 
auxiliary retrieve requests (ARR'S), There must be one RB 
for each RETRIEVE request issued, The exact role that each 
buffer plays is explained in the next section of this 
chapter. In general though, upon successful execution of an 
ARR, all record occurrences satisfying the request are 
maintained in the buffer, This information is then used for 


Subsequent request execution, 


41 


C, MAPPING THE FIND STATEMENTS TO THE ABDL RETRIEVES 


Tne general format of the CODASYL FIND statement is 


FIND record, ,selection.expresslon [ y 


while the general format of the ABDL RETRIEVE is 


RETRIEVE Query Targetelist [ by Attríbutes ]l. 


As previously stated, there are several formats for the FIND 
statement, each with a different functionality, Some of 
these, however, are thought to be considerably more useful 
than others, so we only concern ourselves with the ones of 
most value in the MLDS, Before proceeding, the reader 
should note that in CODASYL statements, upperecase notation 
represents literals, lower-case represents user supplied 
variable names, and square brackets indicate optional 
clauses. We now examine the mapping process for each of the 
CODASYL statements to be included in the MLDS network 
interface, 
1, Zhe ELND ANY Stacanast 

The FIND ANY statement tells the database system to 
locate any record of type, record.typei, whose values for 
itemi through itemn match those in that record*s template in 
the user work area, The syntax for the FIND ANY 1st 


FIND ANY record,.type1 USING itemi, ,,, ,1temn 
IN record,typel, 


To perform the mapping of this statement, the Kernel mapping 
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system (KMS) must first substitute tne word RETRIEVE for the 
words FIND ANY, Then the KMS must form a predicate, (TYPE = 
reCord.typei), for inclusion in the final query, The next 
step in tne process requires the KMS to determine the values 
that the search is to be based on, These values are found 
in record.typei’s record template, 

After acquiring these values, tne KMS then forms 
additional predicates for the data items specified in the 
original statement, and includes these predicates in the 
query, Since all of the necessary information is available 
to the KMS for this particular CODASYL statement, there is 
no need for an @uxilliary retrieve request (ARR), However, 
an RB is needed to store the retrieved data once the request 
has been executed, 

With the query now formed, the KMS creates a 
targetelist to complete the RETRIEVE request, The target» 
list consists of all attributes of the requested record, 


Thus, the translated CODASYL*DML statement 1s: 


RETRIEVE (( TYPE = record, typei) and 
(1itemi = user.,valueli) and 
- and 
(itemn e user, ,valuen)) 
( all attributes ) [ by OBKEY ), 
This request is then passed to the KC of the interface for 
execution, An example utilizina our sample database will 


help to illustrate the mechanics of the mapping process, 
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The requirement is to find any Suppller Pecord, $, 
where that supplier’s city is “Cleveland”, The CODASYL 
procedure is! 

MOVE Cleveland’? TO CITY IN S 
FINO ANY S USING CITY IH S 
(Note: The MOVE statement is an assignment statement found 
in the host COBOL language,) The KMS would respond to this 
series of code by performing the following actions: 
Step 11 Cleveland’? is placed in the S template for the 
attribute CITY, 
Step 23 A RETRIEVE request is formed as such? 
RETRIEVE (CTYPE & 35) and 
(CITY * *Cleveland*')) 


(SNO, SNAME, STATUS, CITY) 
by DBKEY 


Step 3: The KMS passes the request to the KC for 
execution, 

This operation results in having all S records satisfying 

the query ((TYPE = S) and (CITY = °Cleveland’)) placed in 

the request buffer and sorted according to tne value cf the 

database keys, Figure 14 shows the contents of Bufi after 


the RETRIEVE 1s executed, 


¿Parana ASS SSA a 


i | 
| «S6,Mathews,25,Cleveland» | 
' <88,Jones,30,Cleveland> 
| | 


$ 0000000050000 ws» yo 


Figure 143 Contents of Bugi After RETRIEVE, 
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Upon íssuance of a GET statement by the user, the first 
record in tne RB is returned, provided tne RETRIEVE has been 
successful, 
2. Iba EIND CURRENI Stateaneant 

The FIND CURRENT statement 15 a rather simple one in 
that no direct mapping to an ABOL request is necessary, 
This statement is used to change the current of run unit 
indicator from its present value to the value of the 
database key of the current record of set.typel, Tnus, the 
interface has the responsibility of updating the current of 
run unit indicator (1í,e,, CIT,RUN,UNIT,type «-»» record.,typei 
and  CIT,RUN,UNIT,dbkey <we dbkey of current of set..typel), 


The syntax for this statement is! 


FIND CURRENT record.typei WITHIN set.typei 


As an example of this process, suppose we desire to 
start a search at the current SP occurrence in set.tyoe Se 


SP. The CODASYL statement would be: 


FIND CURRENT SP WITHIN SeSP 


After encountering this statement, the KMS passes the update 
information on to the KC for execution, The KC then updates 
the currency indicators to reflect tne cnanaes, The current 
of run unit becomes the current SP record occurrence of the 


current SeSP set occurrence, 
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3.  Ib& EIUD DUBLICATLE 4IIBIN SLatgnant 

Tne FIND DUPLICATE statement is used for sequential 
access within a particular set occurrence, It locates the 
first record.typei record within tne current set.typbel 
occurrence whose values for item! through itemn match those 
of the current record of set.typel, Ihe syntax used for 
this statement is: 

FIND DUPLICATE WITHIN set.typeí USING 
itemi, aes ,ítemn IN record, typel 

The mapping process for this request assumes that 
the records beíng requested are already in an RB, 
Therefore, no RETRIEVE request is generated for this 
Statement, Instead, the KMS forwards the set type, record 
type, and the data item name(s), on which the search is 
based, to the KC, The KC then takes this information, and 
locates the RB containing the set, It then compares the 
specified data item values for the current record of the set 
type to each of the other member records until the first 
duplicate record within the set is found, This record is 
made available for return to the user, Tne CIT is then 
updated to reflect the new currency status, This approach 
is advantageous, in that, all of tne records for à 
particular set occurrence are already available in an RB, 
eliminating the need for further accesses to the database in 
the event of subsequent requests for duplicate records, such 


as would be the case in a loop, 
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The following example {illustrates the maoping 
process: Find the next shipment record for supolier S1 in 
which the quantity snipped is 100, A possible CODASYL 
procedure for accomplishing this consists of the following 
statements? 

MOVE *S1* TO SNO IN S 

FIND ANY S USING SNO IN S 

MOVE 100 TO QTY IN SP 

FIND SP WITHIN SeSP CURRENT USING QTY IN SP 

FIND DUPLICATE WITHIN SSP USING QTY JN SP 
The effect of the first four statements is to locate the 
first SP occurrence for supplier Si that has a QTY of 100, 
The next statement finds the next SP record in the SeSP set 
with the same QTY, namely, 100, 

The interface would respond to tne FIND OUPLICATE 
request as follows! 


Step i: Execution of the first four statements produces 
the results in the RB of Figure 15, 


Step 2: The KC then gets the value of the data item, 
QTY, by going to the RP and finding the current 
record of the SSP set using the record.type and 
set.type information given. 


Step 3t The KC now locates the next record in the set with 
QTY 2 100 and makes it ready for return to the 
user, 
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Figure 15: Contents of bufi, 


4. Ibe EIND EIRSI Statenact 
Tne FIND FIRST statement locates the first member 
record of a set occurrence, This statement has several 
other forms: FINO LAST, FIND NEXT, and FIND PRIOR, Since 
they are all mapped in exactly the same way, we only 
describe the mapping process for the FIND FIRST, The syntax 


for the FIND FIRST is: 
FIND FIRST record.typei WITHIN set.typel 


Upon encountering the FIND FIRST, the KMS must 
ensure that record typeil is a member record type of 
set.typei, This is necessary, since tnis particular FIND tis 
based on the currency indicators, and the current of 
set,typei may be an owner record, as noted earlier when 
discussing currency of set types, Assuming that the current 
record of set.typel is a member record, the KMS then forms a 
RETRIEVE request that will retrieve every member record of 
the current set.typel occurrence into its RB, The interface 
would then only have to return the first record in the set 
in order to satisfy the request, If the statement nad been 


FIND LAST, the last record in the set would be returned, 
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The response would be similar for the FIND NEXT and 
FIND PRIOR statements, Assuming that the set occurrence nas 
already been retrieved into an RB, the interface would 
Simply locate the current record of set.typei in the RB and 
return the record after it ín the case of FIND NEXT, or tne 
record before, it in the case of tne FIND PRIOR, The fact 
that all of the member records of the set occurrence are 
already in an RB, eliminates the need for additional 
database accesses, Thus, the only ABDL request that need pe 
formed is this? 

RETRIEVE (CTYPE & record.typet) and 
(MEMBER, Set.typel 2 owner _,dbkey,set-=typei)) 
(all attributes) (by DBKEY) 

As an example, consider the following request: Find 
all the part numbers (PNO°%s) for parts supplied by supplier 
Sá. A possible CODASYL procedure to accomplish this would 
be; 

MOVE *'S4* TO SNO IN S 
FIND ANY S USING SNO IN S 
MOVE *NO* TO EOF 
FIND FIRST SP WITHIN S=SP 
PERFORM UNTIL EOF m *YES? 
GET SP 
(add PNO IN SP to result list) 
FIND NEXT SP WITHIN S#SP 
END PERFORM 

Tne statements of concern here are the FIND FIRST 
and the FIND NEXT, The reader need only be aware tnat in 
CODASYL only one record at a time is made available to the 


user, Thus, the need for the perform 100P, 
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In response to the above sequence of statements, the 


interface would perform these steps? 


Step 1: The KMS of tpe interface would form a RETRIEVE 
request to get all members of the S#SP set owned 
by supplier S4, Since eacn record has a predicate 
which identifies them as members of a particular 
set occurrence, the task is falrly easy, The re=# 
quest is: 


RETRIEVE CCTYPE = SP) and 

(MEMRER,SeSP zx dbkey of S4)) 

(SNO,PNO,QTY) [by PNO}. 
The results of executing this request are shown in Figure 
16. we can see that every member record of the set has been 
fetched from the database and is available for return to the 
user, The FIND FIRST causes the first record to be returned 
to the user, 

Step 23: Since the CODASYL procedure has a FIND NEXT 
statement, the same RB is used, In other words, 
the KC does not need to execute a new retrieve ree 
quest, It merely makes available the next record 
in the RB until all records have been returned to 
tne user as per the loop, 

Since we are only looking for PNO values, the interim user 
code would specify the attribute to be returned and the 


interface would respond accordinaly,. 
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Figure 163 Contents of Bufl After RETRIEVE, 
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5. 42298 ELUD ObENEB SLatLenant 
The FIND OWNER statement causes the owner of the 
current of set.type occurrence to be returned to the user, 


The syntax for this statement iss: 


FIND OWNER WITHIN set.typel 


Tne mapping of this statement is relatively straiantforward, 
The KMS must simply form a RETRIEVE request based on 
information available in the CIT, Tne KMS examines the CIT 
entry for set.typel and extracts the owner's type and 
database key value directly from the table, It is then an 
easy task to form the request? 
RETRIEVE (CTYPE =. owner of set.typei1) and 
(DRKEY 32 owner dbkey Of set,.typel)) 
(all attributes) 
As an example, suppose we want to Know the STATUS of 
the supplier for part number P6, Let us assume that 
previous statements have set up the current SeSP set 


occurrence to be S2/P6/20, The CODASYL statement i5! 


FIND OWNER WITHIN SeSP, 


In response to this request, the interface takes the 


following actioni 


Step 1: The KMS forms the request! 
RETRIEVE ((TYPE s S) and 


(DBKEY s dbkey of S2)) 
(SNO, SNAME,STATUS,CITY) 
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Step 2: Tne KC would cause the execution of the above 
request, resulting in an RB containing one record, 
namely, the S2 record, 

Based on the interim user code, the STATUS value is returned 
to the user from the RB by the interface, 
6, Ihe ELIUD WITHIN CURBENI Stateneot 
This statement causes the first record within the 
current occurrence of set.typei whose values for itemi 
through itemn match those {in the user xark area for 
record.typoel, The following syntax {8 used for this 
statement, 
FIND recordatypei WITHIN setatypei CURRENT 
USING itemi, ees ,itemn IN record.typel 
This statement is similar to the FIND DUPLICATE 
except that the search values are obtained from the user 
vice the current record of set type, Thus, only a single 
RETRIEVE request is needed, That request taxes the form? 
RETRIEVE ((TPYE = record.type1) and 
(MEMBER,set.typeil zx dbkey of owner set.typel1) 
and (itemi = user valuei) 
and eee 
and (itemn s user valuen)) 
(all attributes) (by DBKEY] 
This request is then passed to the KC for execution, If 
there is more than one record satisfying this query, the RB 
for the request contains them all, However, only the first 
record encountered is returned to the user, 
To illustrate the process of tnis mapping, we return 


to a previous example: FIND the first shipment for supplier 
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Si in which the quantity ts 100, Using the first four 
statements from the example in section C,3 we have, 
MOVE S1 TO SNO IN S 
FIND ANY S USING SNO IN S 
MOVE 100 TO QTY IN SP 
FIND SP WITHIN S#SP 
CURRENT USING QTY IN SP, 


In order to carry out this request, the following steps are 


taken by the interface: 


Step i: The KMS forms the request? 
RETRIEVE ((TYPE s SP) 
and (MEMRER,SeSP z dbkey of S1) 
and (QTY = 100)) 
(SNO,PNO,QTY) [by DBKEY) 

Step 2: The KC executes the above request and causes the 
first record in the RB to be made available to the 
user, 

D, MAPPING THE CODASYL GET STATEMENTS 

The GET statements in the CODASYL*DML can be considered 
as data retrieval statements just as the FIND statements 
are, except that the GET request can only access records 
that have been previously identified by a FIND statement, 
It is the statement that actually gives the user access to 
the individual records, There are three options available 
with the GET statement, and we examine each in turn, In 
developing these mappings, we decided not to directly map 


the GET statements to ABDL RETRIEVE^s, but to simply issue 


instructions to the KC for handling them, 
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1i, Ihe GEI and GET cecatd.tyne Statazeats 
The GET statement, without the specification of a 
particular record type, causes the entire current record of 
run unit, that is, every data field in the record, to be 
returned to the user via the User Work Area (UwaA), In tne 
MLOS network interface, recogniton of this statment by the 
KMS results in the following response: 

Step 1: The KMS informs the KC that the "next" available 
record in the RB that contains records of 
the type CIT, RUN, UNIT,type js to be passed to the 
user, Note that the type of the current of run 
unit does not matter in this case, 

The GET record,type statement is identical to the 
GET option alone, with the exception that the user specifies 
a particular record type, In this case, the KMS must 
determine if the types of the current of run unit matches 
the record type specified before issuing instructions to the 
KC. Also, every data item is returned to the user, 

Returning to our example in section C,4, tne "GET 
SP" statement causes the return of the record, <S4,P2,200>, 
to the user the first time the GET is issued and each of the 
other records in sequence as the loop continues, 

2. eae GEL iteni, ... ,itanan StatenaoL 

Unlike the other GET optíons, this statement causes 

specific data items to be returned to the user, The syntax 


of the statement 151 


GET itemi, eee ,itemn IN record,typel, 
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The KMS must compare the record.type to the current of run 
unit and also ensure that the data items listed match tne 
data items in the record type specified, Once tnis is done 
and is successful, the KMS issues instructions to the KC 
just as in the above case, Only this time, specific data 
items are returned from the records accessed, 

As an example, suppose we wanted only the PNO values 
from the SP records, The value returned from our last 
example would be P2, with subsequent GET statements 


returning each PNO value in succession, 


Es MAPPING THE DATA-UPDATING STATEMENTS 

In this section, we examine the CONNECT, DISCONNECT, 
STORE, MODIFY, and ERASE statements. At this point, the 
reader should have a basic understanding of the mapping 
process as previously described, Thus, for the sake of 
brevity, the reader is referred to (Refs, 7, 9, and 12) for 
detailed descriptions of the statements and any restrictions 
involved with their use, we therefore, confine our 
discussion of these statements to a broad definition, the 
mapping process itself, and in most cases, an example, 

1, Iha CONNECT Statanent 

The CONNECT statement is used for manual insertion 

of the current record of run unit into the current 


occurrences of the set type(s) specified, The syntax is: 


CONNECT record,.type1 TO set.typei, ,,. ,Set.typen, 
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This statement requires that the record,typel record be a 
member of the sets specified and also have an insertion 
clause of MANUAL for those sets, 

The CONNECT statement maps directly to tne ABDL 


UPDATE request, The UPDATE format is: 


UPDATE Query Modifier 


In the case of the CONNECT, the mapping is very simple, 
First, the KMS replaces CONNECT by tne word UPDATE, Then, 
the type and database key of the record to be inserted 1s 
taken from the CIT to form the query ((TYPF 2 record.typel) 
and (DBKEY s CIT,RUN.UNIT,.dbkey)), Finally, in order to 
construct the modifier, the KMS get tne database key of the 
owner of the current occurrence set..typel from tne CIT, The 
KMS then forms the modifier, (MEMBER, set..typel z 
CIT.set.typei.owner.dbkey) for each set type specified, 
Each set type specified has its own Complete UPDATE request 
generated, 

One might ask, why use an UPDATE instead of an 
INSERT request, Well, the difference is that the CONNECT 
statement involves records already in the database, And, 
because the keyword, <MEMBER.seteatype,NULL>, is in the 
record whose connection value is NULL, it becomes a simple 
matter to just update that particular keyword, thereby 
connecting the record, We recall that in an attributeebased 
database, keywords, not pointers, are used to connect one 


record to another, The INSERT statement on the otner nand, 
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involves records not already in the database, Thus, the 
completely translated CONNECT statement is: 
UPDATE (CTYPE = record, ,type1) and 
(DBKEY = CIT,RUN. UNIT, dbkey)) 
(MEMBER, set. typei = CIT,set.,typej,owner_,dbkey) 
2. Zhe DISCOWNECT SLtatgnDapt 

The DISCONNECT is just the opposite of the CONNECT 
statement, It causes the current record of the run unít to 
be disconnected from the set lísted, The set occurrences 
selected are determined by the current of set type 
indicators, Since several set types may be listed in the 
statement, only one statement is needed in order to make 
several removals, The records still remain in the database, 
They are sinply disconnected from specific sets, The syntax 
is: 

DISCONNECT record,.typei FROM 
set.typel, ese. ,set.typen,. 

The DISCONNECT statement requires that record, typel 
be a member of the set types listed, and tnat the record be 
removed from the set occurrences that are current, Because 
of the way we represent set membership in the attribute». 
based record, this task is very simple, Since we are 
disconnecting the current of run unit, and 1t contains the 
database keys of the owners of the set occurrences it 
belongs to, and since each record can only pe in one 


occurrence of the same set type (pairwise disjointness), the 
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mapping process is direct, we simply form an UPDATE request 
for each set type listed, Thus, the keyword, 
X«MEMBER,set.typei,owner.dbkey», is modified, and becomes the 
keyword, «MEMBER,set.typei1,NULL», To accomplish this, tne 
KMS forms the request, 
UPDATE (CTYPE 5s record.typel) and 

(DBKEY s CIT.RUN.UNIT,dbkey)) 

(MEMBER,Set,typel1 = NULL) 
and passes it to the KC for execution, 

3, Ibe 4O0DIEX Stat&enant 
The MODIFY statement causes the entire current 

record of the run unit to be modified or specific data items 


in that record to be modified, The syntax is either, 


MODIFY record.typei1, or 


MODIFY itemi, eee ,itemn IN record.typel, 


This statement algo, has a rather straightforward 
mapping to the ABDL UPDATE request, The statement assumes 
that the user has supplied the necessary data item values 
for modification in record.typei’s record template in the 
UNA, Therefore, the job of the KMS portion of the interface 
is to get this user supplied information and form the 
following UPDATE request for each data item to be modified: 

UPDATE (CTYPE = record.typei) and 


(DBKEY 2 CIT,RUNA,UNIT,dbkey)) 
(data itemi = user value for 1), 


As an example of this process, consider changing tne STATUS 
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and CITY attributes of supplier S4 from 20 and “London” to 
15 and “Chicago”, respectively, The CODASYL request is: 
MOVE S4 TO SNO IN S 
MOVE 15 TO STATUS IN S 
MOVE *Chicaqgo* TO CITY IN S 
FIND ANY S USING SNO IN S 
MODIFY STATUS,CITY IN S, 
(Note: The SNO numbers in this example are unique.) Once 
again tne MOVE statements set up tne S record template for 
use by holding the new values for the S4 record, The FIND 
statement establishes the Sá record as the current record of 
the run unit, The KMS then responds to the MODIFY statement 
by forming the following two UPDATE requests and passing 
them to the KC for execution, 
UPDATE ((TYPE s S) and 
(OBKEY = dbkey of §4)) 
(STATUS xz 15) 
UPDATE ((TYPE 5 5s) and 
(DBKEY s dbkey of S4)) 
(CITY = *'Chicago*) 
If the entire record was to be changed, the first option 
would have been used, requiring the KMS to form an UPDATE 
request for each data item in the S record type, 
4, $58 SIOBE Statenents 
The STORE statement is used in the GCODASYL=»DML to 
insert a new record into the database, Before a new record 
can be inserted though, it must be constructed, This takes 


place in the UWA, The syntax for the STORE is: 


STORE record.typei 
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In mapping the STORE statement, care must be 
exercised in determining the proper Set occurrence in which 
to place a record, 1f it is a member record, Tnis tis 
necessary only in the case of automatic insertion, The 
interface must have access to tne original database 
description in order to determine the set selection 
criterion for each new record to be inserted, The three 
criterion ares: by APPLICATION, by STRUCTURAL, and by VALUE, 
Each of these requires a slightly different mapping. 
Therefore, we examine each individually. 

In addition to the set selection criterion, the 
interface must determine if any data items of the record 
being inserted has a DUPLICATES NOT ALLOWED clause assigned 
to it, In the case that such data items exist, the 
interface must form a RETRIEVE request to determine the 
existence of records in the database that may already nave 
items with the same value as those in the record that is 
about to be stored, Thus, each STORE statement consists of 
at least one ABDL RETRIEVE and one ABDL INSERT request, we 
shall see, however, that additional RETRIEVE’s are necessary 
for the set selection criterion of STRUCTURAL and VALUE, 

a. The STOREebyeApplication Statement 

This method of set selection assumes that the 
proper occurrences of sets are indicated in the CIT, 


Therefore, the KMS forms two requests, the RETRIEVE to 


60 


determine the status of duplicates, and the INSERT request 
which stores the record, The process is as follows: 

Step i: The KMS forms the RETRIEVE below with the search 
based on all data items desiaqnated to have 
DUPLICATES NOT ALLOWED, The values for these items 
in the new record are supplied by the user via 
the UWA record template, 

RETRIEVECC(TYPE * recordutypeli) and 
(data itemi = user yaluel)) 
(OBKEY) (by DBKEY] 

Step 2: The KMS forms the INSERT request 
INSERT(<TYPE, record.typei>,<DBKEY,+*x>, 

«data itemi,user valuel>, 
<MEMBER,set=typej,set_typeií,owner.dbkey>) 
and forwards both requests to the KC for execution, 

Stepb 3: The KC issues the RETRIEVE request, If the RR 
returns with no DBKEYs, then the INSERT request is 
executed, Otherwise, the INSERT is not executed 
and an error condition exists, 

b. The STORE#byeValue Statement 

The byeVALUE set Selection criterion means that 
the set occurrence we need has a data item whose value is 
equal to the value in the specified UWA record template 
which has that data item as one of its fields, The reader 
is referred to Figure 10 for the syntax of the set selection 
Clause of sets SSP and PSP, as examples. This type of 
STORE requires that the data item in question have a 
DUPLICATES NOT ALLOWED clause also, and that the user 
initialize the data item in its UWA record template ovefore 
issuing tne STORE request, 

The byeVALUE criterion thnerefore, places the 


additional requirement on the interface of locating the 
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owner of the proper set occurrence before the new record can 
re inserted into the database, This is accomplished by the 
Issuance of a second RETRIEVE request by tne KC if tne first 
RETRIEVE, as mentioned above, returns NULL, The steps in 
the process are; 

Step 11 The KMS forms the fírst RETRIEVE as above, Then 
for each set type in which the new record is a 
member, a RETRIEVE request is formed to aet the 
owner database key, The request 1S? 
RETRIEVECCTYPE = owner type) and 

(search item = user yalue)) 
(DBKEY) (by DBKEY)], 

Step 21 The KMS forms the following INSERT request? 

INSERT(<TYPE,recordetypel>, 
«DBKEY,***», 


«data itemi,user valuel>, 
X«MEMBER,set.typel,***»5) 


Steo 33: The KC executes the first RETRIEVE to determine if 
duplicates exist, If not, the remaining RETRIEVES 
are executed in turn to get the database keys of 
the owners of the set occurrences to which the new 
record belongs, Once these values are returned, 
the KC finishes building the INSERT request, and 
executes it, 

C, The STOREebyeStructure Statement 
The byeSTRUCTURAL set selection criterion is 
similar to byeVALUE except that the proper set occurrence is 
selected by comparing a data item value in one record type 
to the value of that same data item in another record type, 
From our sample database, we could nave a byeSTRUCTURAL 
clause indicating that the SNO value in S must equal the SNO 


value ín SP, Thus, we must searcn for an SP record 
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occurrence with the same SNO value as that in the S template 
in the UWA, Once again, this data item must have a 
DUPLICATES NOT ALLOWED specification, 

The mapping here is identical to that for the 
by=VALUE case except tnat the second through ith RETRIEVES 
are based on equality of values in seperate records, Since 
the idea is the same, we will not give the specifics of the 
mapping here, It is presented in detail in the Appendix, 

Se Che ERASE Statenents 
The ERASE is the final GCODASYL=-DML statement we 
consider for the MLDS network interface, As implied, it is 
the statement that causes deletion of records from the 
database, There are two options with this statement, as 
previously discussed in Chapter 2, we begin with the simple 


ERASE, The syntax for this ERASE statement is; 


ERASE record.typel 


The ERASE without the ALL option deletes one record 
from the database, namely, the current record of the run 
unit, The only requirement is that the record is not tne 
owner of a noneempty set, This means that in mapping this 
statement, we need to issue a RETRIEVE request prior to the 
deletion request to determine if there are any sets whose 
members are connected to this record. Therefore, for each 
set type in whieh the current of run unit iS an owner, we 
have a predicate in the RETRIEVE query of the form? 


(MEMBER,set.typei za CIT,RUN,UNIT,dbkey), The request ís: 
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RETRIEVECC(MEMBER,set.typel CIT,.RUN,IINIT,dbkey)and 
and 
(MEMBER,set.typen x CIT,.RUN.UNIT,dbkey)) 
(DBKEY) (by DBKEY), 
The next step in the mapping Process is to form a 
DELETE request that deletes the current of run unit, That 
request 1s: 
DELETEC CTYPE * CIT,.RUNUNIT,.type) and 
(DBKEY s» CIT.,RUN.UNIT,.dbkey)). 
So, the KMS in this case issues two ABDL requests to the KC 
for execution, The KC would execute the RETRIEVE first, If 
it results in a NULL RB, then the DELETE is executed, 
Otherwise, the ERASE falls, 
The second ERASE under consideration is the ERASE 


with the ALL option, The ERASE ALL syntax 185: 


ERASE ALL record.typel, 


As mentioned in Chapter 2, this option is like a "vacuum 
cleaner" jin that it deletes every record in the hierarchy 
starting with the current record of tne run unit, Tne 
difference between the mapping of this statement and the 
previous ERASE is that, RETRIEVEs must be formed to get the 
database keys of each member of every set that the current 
of run unit owns, and then RETRIEVES are formed recursively 


thereafter for the members of lower level sets until the 
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leaves of the nierarchy are reached, In addition to these 
RETRIEVE requests, a DELETE request is needed for each 
member of every set connected to the current of run unit and 
the current of run unit itself, As one can see, this coula 
become quite complex, Therefore, we briefly decribe the 
alaorithm, and refer the reader to the Appendix for tne 
details, 

In mapping the ERASE ALL, the KMS forms a RETRIEVE 
reguest to get each member of every set owned by the current 
of run unit, It then forms a DELETE for each of these 
members, Once it nas taken care of the first level, the KMS 
proceeds to form requests which erase all of the descendents 
in tne same fashion by calling a recursive procedure called 
Yeraseeall", Finally, the KMS forms a DELETE request to 
delete the current record of the run unit as in the previous 
ERASE, This concludes the desciptions of the mapping 


process from CODASYLeDML to ABDL, 
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Ve IE&BRLEMEZIAIICH COESIDEBRAIIQNS 


In Chapter 1, we provide a brief description of the four 
modules included in the CODASYL language interface, namely, 
the lanauage interface layer (LIL), the kernel mapping 
system (KMS), the kernel controller (KC), and the kernel 
formatting system (KFS), In this chapter, we present 


considerations for the implementation of the KMS and the KC, 


A. THE KERNEL MAPPING SYSTEM (KMS) 

The KMS is the second module in the "LOS CODASYL 
interface, It is called from the language interface layer 
(LIL) when the LIL receives CODASYL input requests from the 
user, In this section, we discuss the specification of the 
KMS (see Appendix) for the network (CODASYL) interface, we 
describe its operation, present a conceptual view of 1ts 
data structures, and give an example of the KMS translation 
process, Implementations of the KMS for the DL/I and SQL 
interfaces can be found in (Ref, 513pp. 345-80] and (Ref, 
6:pp, 47968], respectively, These implementations provided 
the basic framework for the desígn of the CODASYL KMS, 

The KMS must perform the following functions: (1) parse 
the request to validate tne user*s CODASYL syntax, and (2) 
translate, or map, the request to equívalent ABDL requests, 
Once the necessary ABDL requests have been formed, they are 


made available to the kernel controller (KC) for execution, 
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l. Ibe KYS Earserz/Iranslator 

The grammaredriven parser is the most important 
aspect of the KMS, The YeteAnother=Comoller Compiler (YACC) 
[Ref. 14] is an ideal choice for the Construction of the 
parser. YACC iS a program generator designed for syntactic 
processing of token streams. YACC functions as follows? It 
must be given a specification of the input language 
structure (a set of grammar rules), the code tnat is to be 
invoked when the grammar rules are recognized, and a lows 
level input routine that generates tokens from a regular 
expression input, Given these inputs, YACC generates a 
program that syntactically recognizes tne input language, 
and causes specific user code to be invoked, as required, 
throughout the recogniton process, The user's code nere is 
the code that performs the CODASYL=DML to ABDL translation, 
The Lexical Analyzer Generator (LEX) [Ref, 15) is the lowe 
level input routine that we propose, LEX is a program 
generator designed for lexical processing of input character 
streams, It takes regular expressions as input, and 
generates a program that partitions the input stream into 
tokens, These tokens are then output to the parser for 
further processing, 

The parser produced by YACC consists of a finite- 
state automaton with a stack, It performs a topedown parse, 
with left-toeright scan and one token § lookeahead, Control 
flow within the parser begins at tne highestelevel grammar 


rule, It then descends through the grammar, hierarchically, 
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calling lower» and lower-leve] grammar rules which search 
for the appropriate tokens in the input streams, As these 
tokens are recognized, some portions of the 
mappina/translation code may be invoked directly, In other 
cases, these tokens are propagated pack up the grammar 
hierarchy until a higher-level grammar rule is satisfied, 
Once a rule is satisfied, further translation can be 
accomplished, When all of the necessary lowelevel grammar 
rules have been satisfied, and control has propagated back 
up to the hnighest-]evel rule, tne parsing and mapping 
process is complete, In section 8, we provide an example of 
the parsing and translation process, 
2. Tee KNS Rata Steuctuces 

The KMS needs several different data structures, 
However, we confine our discussion nere to the structures 
which carry the information necessary for the proper 
execution of the translated requests, The structures that 
fall into this category, are the CIT structure, and the 
request nodes which are passed to the KC for execution, A 
description of the minimum requirementg for these structures 
is given below, 

The CIT is described in Chapter 4, This structure 
carries all of the currency information for a particular run 
unit, and is vital to the proper translation and execution 
of CODASYL statements, The LIL of the interface initializes 
the CIT, The KMS has read access to the CIT at all times, 


while all updates of the CIT are done by the KC only, In 
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the following sections, we discuss each of the data 
structures that are directly related to the parsing anda 
translation process, 
a. The *find.node*" Data Structure 

The find, node is created and used any time that 
a CODASYL FINO statement is mapped by the KMS, Since we are 
considering the implementation of six different FIND 
formats, we must ensure that the find.node has at least four 
fields, one identifying the node as a find.node, a second, 
specifying the type of FINO statement that must be executed, 
jes, FIND ANY, FIND CURRENT, FIND OWNER, aná FIND  wITHIN, 
one field to indicate the set type involved, and one field 


to identify the record type used in the statement, 


find,node 


$eoeeeoeomeooemwuaemeeoouwsuw"n»eeo"e"o9"ouned$ 


| FIND | 
| type of FIND | 
| set type | 
| record type i 
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+ + 


pointer to ABDL request(s) 


Figure 171 The *'find.,node* Data Structure, 


In addition to the above information, each 
fínd.node must also have a field which contains a pointer to 
the specific ABDL request that resulted from the mapping 
process, With regard to the FIND CURRENT request and the 


FIND DUPLICATE request, no ABDL request is generated, 
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Therefore, the pointer would be NULL, Figure 17 above 
illustrates the type of structure described, where the dots 
represent any additional implementationedependent 
information which might need to be included, 
b, The *'get.node^ Data Structure 

The get node carries the information that the KC 
needs in order to return the proper data to the user, It 
must have a field identifying it as a get node and a field 
identifying the type of GET format being used, 
Additionally, a field identifying the record type in 
question must also be included, In the case of the GET 
item,list format, the node should include a pointer to a 
list of data item values to be returned, If the format is 
GET record.type, the pointer field would be NULL, and the KC 
would return all attributes of the record, The same is true 
for the simple GET format, Figure 18 is an example of this 


type of structure, 


get.node 
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GET 
type of GET 
record type 


pointer to list of data 
items to be returned 
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Figure 18: The *get,node” Data Structure, 
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Ce The *connect.node' Data Structure 

Ihe connect.node is created and used whenever a 
CONNECT statement is mapped by the KMS, There are two 
primary fields in this node, The first field identifies tne 
node as a connect.node, The second field is a pointer to 
the list of ABDL UPDATE requests generated by the KMS durina 
its arammaredriven parse, This list may contain one or more 
requests depending upon the number of sets that the record 
must be connected to, as described in Chapter 4, Under the 
current implementation of the MBDS, a seperate UPDATE 
request must be executed for each attribute in a record that 
is to be changed, Thus, the need for multiple UPDATE 
requests. Recall, that the attribute to be changed in this 
case is the MEMBER,set.type attribute, Figure 19 shows the 


basic structure for this node, 


connect.node 
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requests 
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Figure 19: The *connect,node" Data Structure, 


d, The *disconnect.node* Data Structure 
The disconnect.node is created and used whenever 
a DISCONNECT statement is encountered by the KMS, The 


fields of this node are exactly the same as those of the 


74 


connect.node, In this case however, the value of the 
attribute MEMBER,set.type is set to NULL, disconnecting the 
record from designated set occurrences, Once again, we have 
an identifier field, and a list of UPDATE requests, 
e, The *modify.node* Data Structure 

As with the disconnect.node, the modify.node is 
also very similar to the connect.node, It is created 
whenever a MODIFY statement is encountered by the KMS, It 
has two fields, an identifier field, and a pointer to a list 
of UPDATE requests, The UPDATE requests in the modify.node 
are used to alter the value of specific data item attributes 
within a particular record, The number of requests on this 
list can vary from one to the maximum number of data items 
in the record, depending on the MODIFY format chosen by the 


user, A 


-— 
A 


EOó— AA a 


f. The 'store.node* Data Structure 

The store.node is the most interesting of the 
data structures presented so far, It must contain at least 
four fields, The first is tne identifier tield, The second 
field is a pointer to a RETRIEVE request, This request is 
generated by the KMS in order to determine the existence of 
duplicate values for data items declared to have DUPLICATES 
NOT ALLOWED in the database schema, The third field of 
importance relates to the set selection criterion for the 
record being stored, I1t is generated to retrieve the owner 


database key(s) of the proper set occurrence(s) for the new 
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record, This request is only generated ín the cases of the 


by#VALUE and byeSTRUCTURAL set selection criterions, 


storesmnode 
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pointer to INSERT request 


Figure 20: The *store.,.node* Data Structure, 


The final fleid required for the store.node is a 
pointer to the INSERT request which will actually cause the 
record to be placed into the database. Figure 20 above is 
an illustration of this data structure, As mentioned 
before, the dots in the figure represent additional 
implementationedependent information, Should the set 
selection criterion be by APPLICATION, tne second RETRIEVE 
pointer would be NULL, 

Je The ’erase,node’ Data Structure 

The final data structure we discuss is the 
erase, node, This node is created whenever an ERASE 
statement 1s mapped by the KMS, If the EKASE without the 
ALL option is mapped, the erasennode must contain the 
following four fields, First, ít must contain an identifier 
field, Second, it must contain a type field with a value of 


NULL, indicating that it does not have the ALL option, The 
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third field in this node must be a pointer to the RETRIEVE 
request that will determine if the record being deleted owns 
a noneempty set, Should this request return NULL, tne KC 
would execute the request stored in the fourth field. Inis 
is the field containing a pointer to tne DELETE request that 
w111 delete tne current record of the run unit, Figure 21 


gives a representation of this structure, 


erase.;node 
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pointer to RETRIEVE request 


| 
i | 
| ) 
| i 
| e | 
| . | 
| | 
| pointer to run,unit DELETE l 
* ~ 


Figure 21: The *erase.node' without the ALL Option, 


The erase.node created for the ERASE witb the 
ALL option will be considerably more complex than tne 
previous case, First, there must be an identifier field and 
à type field, Then there must be two pointer fields, The 
first pointer field will point to tne list of RETRIEVE 
requests generated to get all the descendents of the record 
being deleted, The second pointer field will point to the 
list of DELETE requests generated for each of the descendent 
records,: Finally, the last field in the structure should be 
a pointer to the DELETE request that deletes the current 
record of the run unit, Figure 22 is an example of this 


structure, 
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erase,node 
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| ERASE [ 
| type of ERASE (CALL) | 
| pointer to descendent RETRIEVES | 
| pointer to descendent DELETES | 
| . | 
| e | 
| è | 
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pointer to DELETE 


Figure 22: Tne *erase,.node” with ALL Option, 


B, THE MAPPING PROCESS: AN EXAMPLE 

In this section, we present an illustrative example of 
the parsing and translation processes within the KMS, 
Recall from the previous chapter, that not all of the 
features of  CODASYL are incorporated in our specification, 
Additionally, since we have thoroughly covered the mappings 
in the previous chapter, we do not discuss these 
translations in detail, 

AS an example of the KMS mapping process, we use a 
Simple CODASYL MODIFY request, fe begin our example by 
showing the dml, statement portion of tne KMS, We then step 
through the grammar and demonstrate relevant portions of our 
design in a system specification language (SSL), The reader 
should note that throughout the example, we only show tne 
portions of the SSL that would actually be executed, The 
entire KMS design is shown in the Appendix, The portion of 


the qrammar relevant to this example is shown in Figure 23, 
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In Figure 23, we have included the grammar rules only, and 


not the code to be invoked as eacn rule is satisfied, 


statement: ddl, statement 
| dmi 
; 


dml: dml.statement 
if dml dml.statement 


6 
, 


dml, statements set. flag 
move 

get 

find 

store 
connect 
disconnect 
erase 
modify 
perform.loop 
if tnen 

; 


modify: MODIFY item.list IN record.tyoe 
{ MODIFY record.type 
; 
item;.list: item.name 
| ítem.list COMMA item.name 
3 


record.type: IDENTIFIER 
; 


item;name: IDENTIFIER 
; 
Figure 231 The KMS dml.statement Grammar, 


The source CODASYL procedure we use for our example is: 


MOVE 100 TO QTY IN SP 
MODIFY QTY IN SP, 


Before diving the ABDL equivalent of tnis request, however, 


we must make the assumption that the record being modified 
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is the current record of the run unit. We also assume that 
the database key for this record {s 10, with these two 
assumptions in mind, the ABDI equivalent of tne MODIFY 
statement is; 
(UPDATE ((TFMPLATE = SP) and (DBKEY s 10)) 
(QTY = 100)], 

For the sake of brevity in our example, we will not go 
through the mapping process for the MOVE statement, The 
reader need only be aware that the new value for the 
attribute QTY in the record template for record type SP, has 
been set to the value, 100, by the previous 
parse/translation, Now, we may proceed with the mapping of 
the MODIFY statement, 

At the beginning of the mapping process, the parse 
descends the grammar hierarchy searcning for tokens in the 
grammar rules which match those in the input, Notice that 
the first rule to be tried is the ddl.statement rule, As 
the parse descends the ddil,statement rule, hierarchically, 
there are no tokens which match the example input stream, 
Thus, the ddl.;statement rule is not satisfied, and the parse 
begins again at the dml rule, 

When the dmi rule is called, it immediately calls the 


dml statement rule, 
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dml;staátement: set.flag 
| move 
| get 
| find 
| store 
| connect 
| disconnect 
| erase 
| modify 
l perform.loop 
| if.then 
y. 


The dml, statement rule then calls the set.flag rule, The 
set,.flag rule is not satisfied, however, and the move rule 
is called, It too, is not satisfied. So, the process of 
checking each successive rule is continued until we reach 


the following rule? 


modify: MODIFY 
o adi z NULL 
at IN record.,type 
) /* error checks are made here */ 
alloc and init new modify’ node 


for (each data.nitem on select.list) 
alloc and init new apdl.str 
/* form UPDATE request */ 
copy "(UPDATE ((TEMPLATE =a *'record.type*) 
and (DBKEY & CIT,RUN,UNIT,dbkey))" 
to abdl.str 
get *item,value^ from move.1list 
concat "(*data.item^ s *item.,value*)) 
to abdl.str 
connect abdl.str to *modify” node 
end. for 
end,else 
) 
| MODIFY record.type 
) e 


The modify rule looks for the token, MODIFY, in the input. 
Since it is present, the first portion of the rule matcnes, 
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and the code following the token in the rule is invoked, 
This code simply resets a local list wnich will eventually 
contain the names of the data items which are to pe 
modified, 

The next rule called is the iítf&u.list rule, This rule 
searches for a list of identifiers in the input by calling 
the item.name rule, and recursively cCcallina item.list, as 
indicated, In our example, the single identifier, QTY, 
satisfies the first portion of this rule, namely, item,name, 
Thus, the ¿tem.list rule is satisfied, The syntax for the 


item.list rule is: 


item.list: item,name 
( 
add the item, name 
to select.list 
) 
item.list COMMA item,name 
{ 
add succesive 
item,name to selec.,list 
) 
) 4 


The next portion of the modify rule is the token, IN, 
This token matches the token, IN, in the input stream, and 
the parse continues, Finally, the last portion of the 
modify rule which must pe satisfied is tne pascard type rule, 
This rule ís satisfied by matching the identifier, SP, in 
the input, with the token, IDENTIFIER, in the record.type 


rule, After matching these two, the entire modify rule is 
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Satisfied, and the invocation of the remaining mapping and 
translation code following the rule takes place, 

Tne mapping and translation occurs as follows, First, a 
series of cnecks are made to determine if the record being 
modified is the current record of the run unit, if the new 
value(s) have been placed in the record temolate, and 1f all 
of the items identified in the item list belong to the 
record in question, Tnen, a modify node is created, 
Following this step, an UPDATE request is generated for each 
of the data items being modified, Finally, each of the 
update requests are connected to the modify node for 
execution by the KC, With the mapping and translation code 
executed, the modify rule is completely satisfied, and 
control propagates back up the grammar hierarchy to the dml 
rule which checks for more input, 

As one can see, quite a significant amount of work is 
done by the KMS in preparing requests for use by the KC, Ne 
feel that by adequately providing information to tne KC, we 


greatly reduce the amount of work that must be done by the 


—— 
— 


KC. This means less coding for the implementor and should 


lead to less complexity in the KC, 


C, THE KERNEL CONTROLLER (KC) 

The KC is the third module in the MLDS CODASYL 
interface, It is called by the language interface layer 
(LIL) when a new database is being loaded, and is called by 


the kernel mapping system (KMS) when an existing database is 
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being manipulated, The KC is the module which performs the 
task of controlling the submission of ABOL transactions to 
the multi-backend database system (MBDS) for processing, 
Implementations of the KC for the DL/I and SQL interfaces 
can be found in [Ref, 5:pp, 84-105] and (Ref. 6:p0, 6988), 
respectively, 

The KC must perform the following functions: (1) submit 
transactions to the MBDS, (2) receive and store results of 
transactions, (3) update the currency indicator table, and 
(4) cause the proper data to be returned to the user, 

1. Tbe Structura af tbe KC 

Because of the large number of types of transactions 
that the KC must process, we Suggest that the overall 
Structure of the KC be based on the "case" control 
structure, At tne top of the control structure is a master 
control procedure which 1s responsible for initialization of 
variables, pointers, and data structures, as well as, 
deciding the type of ABDL transaction that is being 
processed, Recall that there are two major types of 
transactions, creation of a new database, and manipulation 
of an existing database, Thus, a two element case is 
required in the master control procedure, These cases are 
then used to call subsequent procedures and functions which 
handle the transactions which fall under the above 


categories, 
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a, Creation of a New Database 

The creation of a new database is the least 

difficult transaction that the KC will nandle, It involves 
loading the CODASYL schema created by the KMS into tne KDS 


—Ó 


—— — MÀ 


(MBDS), in íts attributeeboased form, It 1s also responsible 
for mass storage of new records during a database creation 
transaction, Thus, the KC must also assian database keys to 
the new records throughout this process, 

Currently, work is being done on the algorithms 
necessary to accomplish the transformations above and the 
mass storage requirement. This work will not be completed 
in time for inclusion in this thesis, Suffice it to say, 
however, that once the work is completed, the only 
requirement of the KC in this case, is to call a procedure 
to load the database schema, call a procedure to load the 
database descriptor file, and then call a procedure to load 
the new database, Once these procedures are executed, 
control is returned to the LIL, 

b, Manipulation of an Existing Database 

The manipulation of an existing database can 
also be divided into sub-cases, There are the data 
retrieval requests and the database update requests. 
However, all of these can be handled by a single case 
structure, Recall that each time tne KC is calied, a 
request node of some type is made available to the KC, 
These request nodes are then used to determine which option 


within the case structure to execute, The structure is 


82 


illustrated in Figure 24, In the following sections, we 
present the procedural requirements for each type of data 


manipulation transaction, 


case op.type of 


create,dbs: call load.schema 
call load,descriptors 
call lo&ad.db.recs 


find: case type of 
anys call find, any 
current: call find. current 
duplicate: call find, duplicate 
(first,last, 
next, prior)? call find, conseg 
owner: call find, owner 
end, cases 
(connect, 
disconnect,modify): call update.wdb 
; 
store: call store, rec 
; 
erase: call delete, recs 
; 
get: call get.rec 
; 


Figure 24: The KC Control Structure, 


(1) Iba EINUD Bracadurces. There are six basic 
types of FIND requests utilized in our system, The first of 
these is the FIND ANY request, Upon encountering a 
find.node whose type field is ANY, the findwany procedure is 
called, This procedure sets up the request buffer to 
receive any results that may be returned, It tnen issues 
tne request to the KDS, Upon return from the KDS, the 
find.any procedure must update the CIT, based on the type 


and database key of the record that is the first record in 
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the request buffer, A pointer is then set to point to this 
record in preparation for returning it to the user, The 
record is not returned though, unless the user issues a GET 
request, 

If tne request is a FIND CURRENT request, 
the fíind.current procedure is called, Its job is quite 
easy, It must simply update the CIT, py setting the current 
of run unit indicator to the type and database key of the 
current record of the set type specified in the request 
node, 

When the request is a FIND DUPLICATE 
request, the find.duplicate procedure is called, This 
procedure assumes that the records being requested are 
already in a request buffer, Thus, the only information 
required from the fínd.node is the record.type being 
searched for, the set,type of interest, and the data item 
values on which the search is based, The procedure locates 
the request buffer, and sets a pointer to polnt to the first 
duplicate record found, This record then becomes the record 
returned when the user issues a GET request, The procedure 
also updates the CIT accordingly, 

The next type of FIND request is the FIND 
FIRST, LAST, NEXT, or PRIOR, In these cases, if the type is 
first, last, next, or prior, the find,conseq procedure is 
called, It bases its performance on the type of the 
find;node, If the type is next or prior, the procedure 


assumes that the records are already in a request buffer, 
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It looks for the correct request puffer based on the 
record.type specified in the find.node, and sets a pointer 
to point to the next or prior record relative to the current 
record of the set type this buffer is holding, In otner 
words, each record in the buffer is a member of the Current 
set type occurrence, and the find,;Conseq procedure simply 
points to the record before or after tne Current record for 
that set, Once again, this is the record returned when the 
user issues a GET request, 

If the type of the FIND 1s first or last, 
the find.conseq procedure does the following, First, it 
checks to see if a request buffer exists for the set type 
requested in the find.node, If no such buffer exists, the 
procedure creates a request buffer and issues the RETRIEVE 
request attached to the find,.node, The results of the 
request are then placed in the new request buffer, and a 
pointer is set to point to the "first" or "last" record ín 
the set for return to the user, 

The next type of FIND request is the FIND 
OWNER, when this is the type of the find.node, the 
find.owner procedure is called, It^s function is fairly 
straightforward, A request buffer is created to hold the 
record that is the owner record of the set type indicated in 
the find.node, The find.owner procedure then issues the 
RETRIEVE request attached to the find.node, and prepares the 


record for return to the user, 
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The final type of FIND request, expected by 
the KC, is the FIND WITHIN CURRENT request, In this case, 
the find, within procedure is called. The procedure creates 
a request buffer for the storage of records returned and 
issues the RETRIEVE request associated with tne current 
find.node, Aqain, a pointer 1s set to point to the first 
record in the request buffer in order that this record míiant 
be returned when a GET request is issued by the user, It 
should be noted that in each case above, tne CIT is updated 
unless a currency suppression list has been attached to tne 
find.node in question, 

(2) The COUXECI, DISCOUNECI, aod BODLEL 
Pracedusas. The CONNECT, DISCONNECT, and MODIFY requests 
are handled by the KC in the same general manner, when 
either a modify.node, a connect.node, or a disconnect,node 
is encountered by the KC, tne procedure, update,.db, is 
called, If the node is a modify.node, tne KC simply submits 
the attached ABDL UPDATE requests to the KDS for execution, 
After execution, control is returned to the LIL, 

If tne node passed to proceddure update.,db 
is à connect,node or a disconnect.node, all of the above 
applies, except that before giving control to the LIL, the 
KC must update the CIT, When a record is connected to a set 
type, that record becomes the current record of the set 
type, when a record is disconnected from a set type, the 
entry in for that set type in the CIT is set to NULL and 


remains so until another record of the set type is accessed, 
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(33 rhe SIOBRE Brocadurs. when the KC 
recognizes a store.node, the procedure store.rec is called, 
The first task performed by Sstore.rec is to execute the 
first  RETRIEVE request attached to tne node, This request 
determines 1f there are records in tne database which have 
attribute values that are not to pe duplicated, If the 
request buffer created for this RETRIEVE iS DOD-empty at the 
end of execution, there is an error, If the request buffer 
is aunty , then store.rec performs in the following manner, 
For each RETRIEVE request on the set Select RETRIEVE list, a 
file buffer is created and the RETRIEVE request is issued, 
These requests return the database Keys of the owners of the 
set occurrences to which the new record pelongs, 

After execution of the set select RETRIEVE 
list, the procedure store.rec then assigns a database key to 
the new record, and proceeds to complete the INSERT request 
attached to the store.node, It is very important that the 
order in which the database keys are accessed from tne 
request buffer match the order of the attributes, 
MEMBER,Set.typei, in the INSERT request, The INSERT request 
is then issued, Now, because we nave not accessed this 
record previously, and it nas become the current of run 
unit, store,rec must provide a buffer to hold this record in 
case a GET request is issued immediately following the STORE 
request, An example of this process is warranted at this 
point. Suppose, we desire to store the SP occurrence, 


SS/P6/700, The CODASYL sequence might bes 
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MOVE *S5* TO SNO IN Sp 
MOVE *'Pe* TO PNO IN SP 
MOVE 700 TO OTY IN SP 
MOVE *S5* TO SNO IN S 
MOVE *P6” TO PNO IN P 
STORE SP 
The first three MOVES initialize the new 
record’s data values, The next two MOVE*g are used to aid 
in determining which S and P occurrences the new record 
belongs to, because its set insertion mode was declared to 
be automatic, The KMS takes this information and the STORE 
SP statement, and produces a store.node containing the 
followings 
(Nuplicates RETRIEVE request) 
RETRIEVE ((TYPE = SP) and (SNO = S5) and (PNQ = P6)) 
(DBKEY) 
(List of RETRIEVES to get owner DBKEYs) 
RETRIEVE (CTYPE = S) and (SNO 2 S5)) (OBKEY) 
RETRIEVE (CTYPE = P) and (PNO s P6)) (DBKEY) 
(INSERT request for new record) 
INSERT (<TYPE,SP>,<DBKEY,***>,<SNO,S5>,<PNO,P6>, 
X«MEMBER,SeSP,****»,C«MEMBER,PeSP,****») 
We assume, for the sake of our example, 
that the OBKEYs for the owner records are 10(S) and 12(P), 
and that the DBKEY of the new record is 98, We also assume 
that there is no duplicate SP record in the database, So, 
when store.rec issues the first RETRIEVE, the request buffer 
returned is empty, 
Store.rec then proceeds to execute the list 


of RETRIEVES that return the owner OBKEYs of tne new record, 


It creates a request buffer tor the first RETRIEVE on the 
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list and issues the request, Once the first request is 
executed, a buffer is created for the second request, and 
that request is executed, The issuance of these RETRIEVES 
produces the results in the request buffers depicted in 
Figure 25, The procedure store.rec now takes tne new DBKEY 
value, and the information from the request puffers and 
completes the INSERT request, 
$eee mem. 
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Figure 25: Buf1 and Buf2 After Execution, 


The final form of the INSERT request is! 


INSERT (<TYPE,SP>,<DBKEY,98>,<5NO,S5>,<PNO,P6>, 
<MEMBER.S”SP,10>,<MEMBER,P=SP,12>) 
The INSERT request is then issued to the KDS, If no 
currency suppression list is attached to the store,node, the 
CIT is updated to reflect a change in the SeSP and PeSP 
currency as well as, the current of run unit, A request 
buffer is also created, and the record is stored in the 
buffer, As one can see, the store,.rec procedure can be a 


very comprehensive one, 
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(4) Tbe ERASE ELrocadures. The ERASE request is 
handled by the procedure, delete, recs. If the type of the 
erase.node is NULL, then delet.recs proceeds in tne 
following manner, First, a request puffer is created, and 
the RETRIEVE request attached to the erase,node is issued to 
the KDS, This request determines if the record being 
deleted is an owner of a non="empty Set, If the request 
buffer is not empty after execution of tne RETRIEVE, then 
the erase falls, and we have an error condition, If tne 
request buffer is empty after execution of the RETRIEVE, 
then delete.recs issues tne DELETE request attached to tne 
erase.node, This request deletes tne current record of the 
run unit, After the deletions, delete.recs updates the CIT 
by setting the current of run unit indicator to NULL, 

Should the type of the erase.node be ALL, 
we have a different sequence of events, The delete-recs 
procedure must create request buffers for each RETRIEVE 
request on the descendent retrieve list in tne erase node, 
It must then issue each of these RETRIEVES storing the 
results, returned DBKEYs, in the proper request buffer, 
After the list of RETRIEVEs has been issued, the delete.recs 
procedure then completes the DELETE requests attacned to the 
erasennode and issues each DELETE request to the KDS for 
execution, Once again, the CIT 15 updated to reflect the 
change in currency 1,e,, current of set.types become NULL as 


appropriate, 
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(5) bea GEI BRrocadura, The GET request is 
handled by the Gqget.rec procedure, Tnís procedure nas a 
relatively easy task. It simply looks at the type of the 
get.node, examines the record.type involved, and retrieves 
either the entire record of specific fields of the record 
from the request buffer in which the record resides, The 
GET request operates on the current of run unit, so, the 
request buffer in question should be the request buffer 
containing the current record of the run unit, provided tne 
current record of the run unit is not NULL, Finally, the 
reader snould note that with each of tne above procedures, 
deallocation of request buffers when they are no longer 
required, is also an important consideration in this 


process, 
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VI. COUCLUSLONA 


As mentioned in the introduction, the conventional 
approach to database system development has resulted in 
numerous singleemodel, singleelangquage systems witn little, 
if any, flexibility or extensibility. In addition, these 
systems are Slow compared to the system proposed py tnis 
research effort, Our system, the multielingual database 
system (MLDS), provides an alternative to the development of 
seperate standealone database systems wnich use single data 
models, The MLDS will bring flexibility, extensibility, and 
efficiency to the world of database management, The MLDS 
will be able to execute transactions written in any of four 
welleknown and important data lanauages, namely, DL/I, SQL, 
CODASYL, and Daplex, 

In this thesis, we have presented a methodology for 
supporting network database management within the MLDS, 
Specifically, we nave provided a data model transformation 
Strategy, and a data language translation strategy for the 
network data model and the CODASYL data language, 
respectively, We have presented a design specification for 
the kernel mapping system (KMS) to be used in the CODASYL 
interface, A discussion of the concepts involved and the 
data structures necessary for the interface to work properly 


has also been presented, 
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One of the design goals of this project was to make the 
interface as compatible as possible witn the designs of the 
DL/I and SQL interfaces in order to fully utilize existing 
software, The Daplex interface is not mentioned here, 
because it is being developed in parallel with the  CODASYU 
interface, By pursuing this goal, we also eliminate tne 
need for changes in the *BDS and the  A8DL, Thus, it is 
recommended tnat the implementation of tne CODASYL interface 
follow closely, the implementations of the OL/I and SOL 
interfaces, The implementor(s) Snould pay particular 
attention to any commonalities between funtions and data 
structures, 

we feel that the work presented herein is sufficient for 
implementation of the CODASYL interface, All that remains 
is for the code to be written, and placed in the host 
computer, Once the CODASYL interface and the Oaplex 
interface have been completely implemented, the system 
snould be tested as a complete system for projected 
efficiency, effectiveness, and responsiveness to user needs, 
It is anticipated that this research and development effort 
will ultimately result in a new era for database management 
that will allow for increased productivity and profitability 


in the marketplace, 
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APPENDIX - THE KMS PROGRAM SPECIFICA 170m 


Currency Indicator Table 
References made in the following specification to CIT refer to the Currency Indicator Table. 
This table consists of structures that hold information identifying the current record of record- 
type, set-type, and run-unit (run-unit is the application program being run). The following is the 
proposed structure for this table [Ref. 13]. 
struct CIT 


struct RUN-UNIT *run; 
struct rec-type-node *next-rec-type; 
struct set-type-node *next-set-type; 


j 
struct RUN-UNIT 


char rec-typel |; 
int dbkey; 


) 


For each record type in schema: 
struct rec-type-node 
( 
char type| |; 
int dbkey; 


struct rec-type-node *next-rec-type; 


} 


For each set type in schema: 
struct set-type-node 


{ 


boolean OWNER; 
char TYPE| |; 
int dbkey; 

char member| |; 
char owner| |; 
int owner-dbkey; 


struct set-type-node  "next-set-type; 
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76) 


boolean: first-move = TRUE /* flag for MOVE operation */ 

boolean: first-time — /* general purpose flag */ 

boolean: sys-flag-value /* boolean value of system flags */ 

ptr: curr-temp-rec /* ptr to last record added to move-list */ 

ptr: curr-temp-item  /* ptr to next item node to be added to 
record-template node of movelist */ 

list: suppression-list /* list of record types and/or set types */ 
for which currency updates are suppressed */ 


list: select-list /* list of data items used for record section */ 
list: connect-list /* list of sets to which current of run 

unit is to be connected or disconnected */ 
list: tgt-list /* list of attribute names to be accessed */ 
list: move-list /* list of record templates used with 


MOVE statement */ 
list: curr-non-dup-list /* list of data items for which duplicates 
are not allowed in current record-type */ 
int: level-number /* level of data item in record types */ 
char: member-type /* string variable to hold a name */ 
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start statement 


statement: ddl-statement 
| dml 


3 


dml: dml-statement 
| dml dml-statement 


) 


ddl-statement: schema-defn record-list set-list 


schema-defn: SCHEMA NAME IS schema-name SEMI-COLON 


locate db-id schema header node 
if (db names do not match) 
print. ("Error-given db-name doesn't 
match name in file") 
perform yyerror() 
return 
end-if 
initialize db-key /* starting value is 1 */ 


} 


record-list: record-desc 
set db-id node ndn-first-rec ptr 


| record-list record-desc 


{ 


connect successive record nodes 


} 


3 


record-desc: record data-item-list 


{ 


curr-non-dup-list = NULL 


} 


record: RECORD NAME IS 


allocate and init a new 
record node (NREC-NODE) 


allocate curr-non-dup-list 
db-id-node ndn-num-rec++ 


} 


record-spec 


3 
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record-spec: record-t y pe 


if (record-type not defined yet) 
copy record-type to current 
record node (NREC-NODE) 
make this the current record node 
end-if 
else 
print ("Error-'record-type' record 
doubly defined") 
perform yyerror() 
return 
end-else 


) 
SEMI-COLON duplicates-list 


, 


set-list: empty 
| set-desc 


set db-id node ndn-first-set ptr 


| set-list set-desc 


{ 


connect successive set node(s) 


j 


set-desc: set-desig owner-spec member-spec 


3 


set-desig: SET NAME IS 


allocate and init a new set node (NSET-NODE) 
db-id-node ndn-num-set++ 


j 


set-ty pe 


if (set-type not yet defined) 
copy set-type to current set node (nsn-name) 
establish curr-set-ptr 

end-if 

else 
print ("Error-'set-ty pe? set doubly defined in db") 
perform yyerror() 

end-else 


j 
SEMI-COLON 


) 


97 


owner-spec: OWNER IS aa SEMI-COLON 


3 


aa: record-type 


if (record-type not defined) 
print ("Error-’record-type’ record does not exist") 
perform yyerror() 
return 

end-if 

else 
copy record-type to current set node (nsn-owner-name) 
locate record-type node 
nsn-owner(ptr) = record-type node 

end-else 


} 
| SYSTEM 


3 


member-spec: MEMBER IS record-type 


if (record-type not defined) 
print ("Error-'record-ty pe' record does not exist") 
perform yyerror() 
return 

end-if 

else 
copy record-type to current set node (nsn-member-name) 
locate record-type node 
nsn-member(ptr) = record-type node 

end-else 


SEMI-COLON insert-clause retention-clause 
alloc set-select node 


set-select-clause SEMI-COLON 


3 


duplicates-list: empty 
| dup] SEMI-COLON 


? 


dupl: duplicate-spec 
| dupl duplicate-spec 


) 


duplicate-spec: DUPLICATES ARE NOT ALLOWED FOR item-spec 


, 
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Item-spec: item-name 
alloc new non-dup node 
copy item-name to non-dup node 
add non-dup node to curr-non-dup-list 


| item-spec COMMA item-name 


alloc successive non-dup nodes 
copy successive item-names to non-dup nodes 
add successive non-dup nodes to curr-non-dup-list 


j 


data-item-list: item-desc 


{ 


connect new attr-node to record-node 


| data-item-list item-desc 


{ 


connect successive attr-node(s) to record-node 


} 


item-desc: level-num 


{ 
allocate and init a new attr-node (NATTR-NODE) 


NATTR-NODE nan-level-num = level-number 
record-node nrn-num-attr++ 


} 


data-item-desc 


if (nan-level-num = level number of current attribute node) 
connect new attr node to current attr node 
if (nan-level-number > 1) 
connect nan-parent ptr of new node 
end-if 
end-if 
else if (nan-level-number > level number of current attr node) 
connect nan-child ptr of current attr node to new attr node 
connect nan-parent ptr of new attr node to current attr node 
end-else-if 
else 
locate last attr node with same level number 
set that node’s nan-next-attr ptr to the new attr node 
update current attr pointer 
end-else 


j 
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data-item-desc: item-name 


( 


copy item-name to attr-node (NATTR-NODE) 

if (item-name not on curr-non-dup-list) 
attr-node nan-dup-flag — 1 

end-if 


} 
SEMI-COLON data-type PERIOD 


> 


level-num: empty 
level-number = 1 /* default value */ 
} 
| INTEGER 


{ 
level-number = INTEGER 
} 


data-type: CHARACTER INTEGER 


{ 
attr-node nan-lengthl = INTEGER 


attr-node nan-length2 = 0 
attr-node nan-type = 'c' 


} 
| FIXED INTEGER 


attr-node nan-lengthl = INTEGER 
attr-node nan-length2 = 0 
attr-node nan-type = ’1’ 


} 
| FIXED INTEGER 


{ 
attr-node nan-lengthl = INTEGER 


) 
INTEGER 


{ 
attr-node nan-length2 = INTEGER 


attr-node nan-type — 'f 


j 
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insert-clause: INSERTION IS AUTOMATIC 
{ 


set-node nsn-insert = ’a’ 


| INSERTION IS MANUAL 
{ 


set-node nsn-insert — 'm' 


j 


retention-clause: RETENTION IS FIXED 
{ 


set-node nsn-retent = ’f? 


| RETENTION IS MANDATORY 
{ 


set-node nsn-retent = ’m’ 
| RETENTION IS OPTIONAL 
{ 


set-node nsn-retent = ’o’ 


} 


set-select-clause: empty 
set-node nsn-select = 'o' 


| SEMI-COLON SET SELECTION IS BY set-select-spec 


2 
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set-select-spec: VALUE OF item-name IN record-type 


if(valid-attr(item-name;,record-type)) 
copy 'v! to set-select node select- mode 
copy item-name to set-select node item-name 
copy record-type to set-select node record] 
copy BLANK to set-select node record2 
end-if 
else 
print("Error-’item-name’ not valid for ’record-type’") 
perform yyerror() 
return 
end-else 


j 
| STRUCTURAL item-name IN record-type 


if(valid-attr(item-name,record-type)) 
copy ’s’ to set-select node select-mode 
copy item-name to set-select node item-name 
copy record-type to set-select node record] 
end-if 
else 
print("Error-’item-name’ not valid for ’record-type’") 
perform yyerror() 
return 


} 


EQ item-name IN record-type 


if(previous item-name equals this item-name) 
if(valid-attr(item-name,record-type)) 
copy record-type to set-select node record2 
end-if 
else 
print("Error-’item-name’ is not valid for ’record-type’") 
perform yyerror() 
return 
end-if 
else 
print("Error-’item-name’ items do not match") 
perform yyerror() 
return 
end-else 


) 
APPLICATION 
{ 


copy 'a! to set-select node select-mode 
copy BLANK to record1, record2, item-name 
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dml-statement: set-flag 
| move 


| get 

| find 

| store 

| connect 

| disconnect 

| erase 

| modify 

| perform-loop /* not designed */ 
| if-then /* not designed */ 


set-flag: MOVE f-value TO f-name 
f-value: YES 
sys-flag-value = TRUE 
j 
| NO 


sys-flag-value — FALSE 


f-name: EOF 
( 


eof = sys-flag-value 


j 
| NOTFOUND 


notfound = sys-flag-value 


j 
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/* The MOVE statement is a COBOL assignment statement that assigns a */ 
/* value to a particular data field in a record template. We usea  */ 
/* list structure for this purpose. ae 


move: MOVE item-value 


if (first-move = TRUE) 
alloc and imt move-list 
first- nove — FALSE 
end-if 
create new data-item-node 
copy 'item-value” to value field in data-1tem-node 
establish curr-temp-item pointer 


j 


TO ¡tem-name 


{ 


copy 'item-name' to name field in data-item-node 


) 


IN record-type 


if (item-name not in record-type for current schema) 
perform error(2) 
return 
end-if 
else if ('record-type' node on inove-list) 
connect curr-temp-item to record-template node 
end-else-1f 
else 
create new record-template node 
copy 'record-type' to name field of record-template node 
connect curr-temp-item to record-template node 
add record-template node to move-list 
update curr-temp-rec pointer 
end-else 


, 


/* The GET statement takes the entire current record of the run unit */ 
/* or specified data fields of the current record of the run unit */ 
/* and returns the values to the user. P 


get: GET 


alloc and init new 'get? node 
select-list = NULL /* reset select-list */ 


) 


mm 


) 
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mm: item-list IN record-type 


{ 
if ('record-type' is not equal to CIT. RUN-UNIT type) 
perform error(3) 
return 
end-if 
else 
get-type — ITEMS in get node 
copy record-type to get node 
for (each data-item on item-list) 
if ("data-item? is not defined for record-type) 
perform error(2) 
return 
end-if 
else /* create pseudo tgt-list */ 
copy data-item to get node 
end-else 
end-for 
end-else 


| record-type 


if ('record-type' is not equal to CIT.RUN-UNIT type) 
perform error(3) 
return 
end-if 
else 
get-type = RETURN-ALL in get node 
copy 'record-type' to get node 
end-else 


} 


| empty 


get-type = RETURN-ALL in get node 
copy CIT.RUN-UNIT.type to get node 


) 


/* The FIND statements establish the current of run unit, record type, */ 
/* and set type. D. 


find: FIND record-selection-expr curr-suppression 


3 
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/* The FIND ANY means: find any record of type record-ty pe whose */ 
/* values for item1 through itemn match those in that record's */ 
/* template in the user work area. wi 


record-selection-ex pr: ANY record-type 


if. ('Irecord-type' record-template node is not 
on move-list ) 
perform error(1) 
return 
else 
alloc and init new ‘find’ node 
find-type = ANY in find node 
copy record-type to find node 
alloc and init new abdl-str 
alloc and init new tgt-list 
/* begin forming a RETRIEVE request */ 
copy " RETRIEVE ((TEMPLATE = ’record-type’)" 
to abdl-str 
end-1f 
select-list = NULL 


USING item-list IN record-type 


if ("record-type? is same as previous *record-type?) 
if (any data item on select-list 1s not 
defined for record-ty pe) 
perform error(2) 
return 
end-if 
else 
create tgt-list item for all attributes 
of ’record-type’ record 
for (each data item on select-list) 
if ('data-item? not on move-list) 
perform error(1) 
return 
end-if 
else 
get ’item-value’ from move-list 
concat "and (’data-item’ = ’item-value’)" 
to abdl-str 
end-else 
end-for 
concat "J('tgt-lis) by DBKEY]" to abdl-str 
connect abdl-str to find node 
end-else 
end-if 
else 
perform error(6) 
return 
end-else 


j 
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/* The FIND CURRENT means: Make the current of set-type the current */ 
/* record of the run unit. 2 


| CURRENT record-type WITHIN set-type 


if (CIT.set-ty pe. TYPE is not equal to 'record-ty pe") 
perform error(7) 
return 

end-if 

else 

/* current of run-unit becomes current of 'set-type' */ 

alloc and init new "find? node 
find-type = CURRENT in find node 
copy record-type to find node 
copy set-type to find node 
copy CIT.set-type.dbkey to find node 

end-else 


} 
/* The FIND DUPLICATE means: Find the first record in the current set- */ 


/* type occurrence whose value for item] through itemn matches those */ 
/* for the same items in the current set-type occurrence, not the UWA */ 
/* record template. This implementation assumes the records being re- */ 
/* quested are already in a buffer. a 


| DUPLICATE WITHIN set-type 


alloc and init new ’find’ node 

find-type = DUPLICATE in find node 
copy set-type to find node 

select-list = NULL /* reset select-list */ 


} 
USING item-list IN record-type 
{ 
if ((record-type is not CIT.set-type. TYPE) or 
(record-type is not CIT.set-type.member)) 
perform error(8) 
return 
end-if 
else 
copy record-type to find node 
for (each data-item on select-list) 
if (any data-item on select-list is not 
defined for record-type) 
perform error(2) 
return 
end-if 
else /* create a pseudo tgt-list */ 
copy data-item to find node 
end-else 
end-for 
end-else 


j 
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/* This statement means: Find the FIRST, LAST, NEXT, or PRIOR record- */ 

/* type record within the current set-type occurrence. The ll token */ 

/* takes the value FIRST, LAST, NEXT, or PRIOR. il 
| ll record-type WITHIN set-type 


if (record-type’ is not a valid member type 
for 'set-ty pe!) 
perform error(5) 
return 
end-1f 
else 
copy record-type to find node 
copy set-type to find node 


/* RETRIEVE all member records of set occurrence */ 


alloc and init new abdl-str 

alloc and init new tgt-list 

copy "IRETRIEVE ( 
(TEMPLATE = CIT set-type.member) and 
(MEMBER .set-type = CIT set-type.owner-dbkey))" 
to abdl-str 

create tgt-list for all attributes of member record 

concat "(’tgt-list’) by DBKEY]" to abdl-str 

connect abdl-str to find node 

end-else 


} 


/* The FIND OWNER means: Find the owner of the current set-type occurrence */ 
| OWNER WITHIN set-type 


alloc and init "find? node 
find-type = OWNER in find node 
copy set-type to find node 

alloc and init new abdl-str 

alloc and init new tgt-list 


/* form RETRIEVE request */ 


copy "IRETRIEVE ((TEMPLATE - CIT.set-ty pe.owner) 
and (DBKEY - CIT .set-type.owner-dbkey))" 
to abdl-str 

create tgt-list for all attributes of owner record 

concat "(’tgt-list’)|" to abdl-str 

connect abdl-str to find node 


} 
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/* This statement means: Find the first record-ty pe record within the */ 
/* current set-ty pe occurrence whose values for item1 through itemn  */ 
/* match the values found in the record-type template in the UWA, not */ 
/* the values in the current of set-type as in the FIND DUPLICATE.  */ 


| record-type WITHIN set-type CURRENT 


if ('record-type' not a member type of 'set-ty pe") 
perform error(5) 
return 

end-if 

else 
alloc and init new "find? node 
find-type = WITHIN in find-node 
copy record-type to find node 
copy set-type to find node 
alloc and init new abdl-str 
alloc and init new tgt-list 


/* begin forming RETRIEVE request */ 


copy "RETRIEVE ((TEMPLATE = ’record-type’) and 
(MEMBER. set-type = CIT.set-ty pe.owner-dbkey)" 


to abdl-str 
create tgt-list for all attributes of ’record-type’ 
record 
select-list = NULL /* reset select-list */ 
end-else 


USING item-list IN record-type 
{ 
if (any data-item on select-list is not defined 
for ’record-type’) 
perform error(2) 
return 
end-if 
else if (any data-item on select-list 
not on move-list) 
perform error(1) 
return 
end-else-if 
else 
for (each data-item on select-list) 
get '"item-value' from move-list 
concat "and (’data-item’ = ’item-value’) 
to abdl-str 
end-for 
concat "')(’tgt-list’?) by DBKEY]" to abdl-str 
connect abdl-str to find node 
end-else 


} 
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Il: PIRST 


alloc and init new "find' node 
find-type = FIRST in find node 


j 
LAST 


alloc and init new ’find’ node 
find-type = LAST in find node 


j 
NEXT 


alloc and init new "find! node 


find-type = NEXT in find node 


j 
PRIOR 


alloc and init new "find! node 
find-type = PRIOR in find node 


curr-suppression: LSQUARE supp-expr RSQUARE 
| empty 


3 


supp-expr: SUPPRESS UPDATE 
| UPDATE type-spec 


ty pe-spec: set-ty pe 
add set-type to suppression-list 
| type-spec COMMA set-type 


add successive set-types to suppression-list 


j 
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/* This statement means: Delete the current record of the run unit,  */ 
/* and all of its descendents regardless of whether they are owners of */ 
/* other sets. e] 


erase: ERASE ALL record-t y pe 


( 
if ('record-type' is not CIT.RUN-UNIT type) 
perform error(3) 
return 
end-if 
else 
alloc and init new 'erase'! node 
erase-type — ALL in erase node 
for (each set-type in schema) 
if (CIT.set-type.owner-dbkey = CIT.RUN-UNIT.dbkey) 
member-type = CIT. .set-type.member 


/* form RETRIEVE to get member records */ 

alloc and init new abdl-str 

copy'[RETRIEVE(MEMBER.set-type — CIT.RUN-UNIT.dbkey) 
(DBKEY) by DBKEY]" to abdl-str 


connect abdl-str to erase node 


/* erase member records */ 

alloc and init new abdl-str 

copy"[DELETE((TEMPLATE = ’member-type’) and 
(DBKEY = ***))]" to abdl-str 


connect abdl-str to erase node 


/* delete all descendants of member records */ 
perform erase-all(member-type,erase node) 
end-if 


end-for 


/* delete current of RUN-UNIT */ 
alloc and init new abdl-str 
copy "IDELETE((TEMPL ATE - 'record-type') and 
(DBKEY = CIT.RUN-UNIT.dbkey))]" to abdl-str 
connect abdl-str to erase node 
end-else 


j 
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/* This statement means: Delete the current record of the run unit if */ 
/* and only if, it is not the owner of a non-empty set. g. 


| ERASE record-type 


if ('record-type! is not CIT.RUN-UNIT.type) 
perform error(3) 
return 

end-if 


else 


/* erase one record - current of RUN-UNIT */ 
alloc and init new ’erase’ node 
erase-type = NULL in erase node 


/* form RETRIEVE to see if ’record-type’ is */ 
/* owner of non-empty set yf 
alloc and init new abdl-str 
copy " RETREIVE(" to abdl-str 
first-time = TRUE 
for (each set-type in schema) 
if ('record-type' is owner type of set-type) 
if (first-time) 
concat "(MEMBER.set-type = CIT.RUN-UNIT dbkey)" 
to abdl-str 
first-time = FALSE 
end-1f 
else 
concat "or (MEMBER .set-type = CIT.RUN-UNIT.dbkey)" 
to abdl-str 
end-else 
end-1f 
end-for 
concat ")(DBKEY) by DBKEY]" to abdl-str 


connect abdl-str to erase node 


/* for DELETE request */ 
alloc and init new abdl-str 
copy "IDELETE ((TEMPLATE - CIT.RUN-UNIT.type) and 
(DBKEY = CIT.RUN-UNIT.dbkey))¡" to abdl-str 
connect abdl-str to erase node 
end-else 


j 
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/* The STORE means: Create a new record in the database using values */ 

/* supplied by the user via MOVE statements, for the data items of */ 

/* the specified record-type. The is connected to all sets in which */ 

/* INSERTION IS AUTOMATIC. The appropriate occurrence of the sets */ 
/* must be selected before the new record can be connected. This is */ 

/* done based on the SET SELECTION clause specified in the database */ 


/* schema definition for the sets in question. a 
store: STORE record-type 


if ('record-ype' record template node is not on move-list) 
perform error(1) 
return 
end-if 
alloc and init new ’store’ node 
alloc and init new abdl-str 
copy "[RETRIEVE (" to abdl-str 
first-time = TRUE 
for (each data-item in schema for ’record-type’) 
if (nan-dup-flag is set) 
if (data-item in move-list ’record-type’ record template) 
get data-item value from move-list 
if (first-time = TRUE) 
concat"((TEMPLATE = ’record-type’) and 
(-data-item’ = ’item-value’))" to abdl-str 
first-time = FALSE 
end-if 
else 
concat "or ((TEMPLATE = ’record-type’) and 
('data-item' — "item-value?))" to abdl-str 
end-else 
end-1f 
end-if 
end-for 
concat")(DBKEY) by DBKEY]" to abdl-str 
connect retrieve request to store node 
alloc and init new abdl-str 


/* Form an INSERT request */ 
copy"[INSERT (<TEMPLATE)'record-type'>,<DBKEY,***>" to abdl-str 
for (each 'data-item' in schema for ’record-type’) 

if ("data-item” not on move-list for 'record-ty pe!) 
perform error(4) 
return 

end-if 

else 
get data-item value from move-list 
concat",<’item-name’,’item-value’>" to abdl-str 

end-else 

end-for 
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/* Now determine which set occurrences the new record belongs to */ 
/* and add proper attribute-value pairs to the INSERT abdl-str to */ 
/* indicate set membership. The following FOR loop and CASE state-* / 
/* ment fill the INSERT abdl-str with the proper pairs. "n 
for (each set-type in schema in which ’record-type’ is a member) 
case (set selection mode) of 


/* set selection is by applicaton */ 
a: perform by-application(INSERT abdl-str) 


/* set selection is by value */ 


v: perform by-value(INSERT abdl-str) 


/* set selection is by structural */ 


s: perform by-structural(INSERT abdl-str) 


/* no set selection criteria was given */ 


o: perform by-default(INSERT abdl-str) 


end-case 
end-for 
concat "|" to INSERT abdl-str 
connect INSERT abdl-str to store node 
alloc and init suppression-list 


j 


curr-suppression 


{ 


connect suppression-list to store node 
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/* The MODIFY means: Modify the entire current record of the run unit */ 
/* or the specified data items in that record. The new values are — */ 


/* supplied by the user via the UWA. E 
modify: MODIFY 
select-list — NULL  /* reset select-list */ 
item-list IN record-type 


if ('record-type' is not current of run unit) 
perform error(3) 
return 
end-if 
if ('record-type? record-template node is not on move-list) 
perform error(1) 
return 
end-if 
if (any data item on select-list not defined for ’record-type’) 
perform error(2) 
return 
end-1f 
else 
alloc and init new ’modify’ node 
locate record-template node on move-list for ’record-type’ 
for (each data-item on select-list) 
alloc and init new abdl-str 
/* form UPDATE request */ 
copy "| UPDATE ((TEMPLATE = ’record-type’) and 
(DBKEY = CIT.RUN-UNIT.dbkey))" to abdl-str 
get '"item-value' from move-list 
concat "('data-item" — ’item-value’)|" to abdl-str 
connect abdl-str to 'modify' node 
end-for 
end-else 


} 
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| MODIFY record-ty pe 


select-list = NULL /* reset select-list */ 
if ("record-type? not current of run unit) 
perform error(3) 
return 
end-if 
if ('record-ty pe' record-template node is not on move-list) 
perform error(1) 
return 
end-if 
else 
alloc and init new 'modify' node 
for (each data-item in record-type) 
if (data-item not on move-list for ’record-ty pe’) 
perform yyerror(4) 
return 
end-if 
else 
alloc and init new abdl-str 


/* form an UPDATE request */ 
copy "| UPDATE ((TEMPLATE = ’record-type’) and 
(DBKEY = CIT.RUN-UNIT.dbkey)) to abdl-str 
get new "item-value' from move-list 
concat "('data-item' = 'item-value”)|" to abdl-str 
connect abdl-str to 'modify' node 
end-else 
end-for 
end-else 


j 
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/* The CONNECT means: Connect the current record of the run unit to the */ 
/* current occurrence of the specified set type. There may be several */ 
/* sets listed in the statement. E 


connect: CONNECT record-type TO 


if ('record-type' is not current of run unit) 
perform error(3) 
return 

end-if 

else 
alloc and init connect-list 

end-else 


} 


set-ty pe-list 


alloc and init ’connect’ node 
for (each ’set-type’ on connect-list) 
If ('record-type' is not à member type record for ’set-type’) 
or (INSERTION is not manual) 
perform error(5) 
return 
end-if 
else 
alloc and init new abdl-str 
copy "UPDATE ((TEMPLATE - ’record-type’) and 
(DBKEY = CIT.RUN-UNIT dbkey)) 
(MEMBER .set-type = CIT.set-type.owner-dbkey)]" 
to abdl-str 
connect new abdl-str to 'connect! node 
end-else 
end-for 
connect-list — NULL  /* reset connect-list */ 


j 


set-type-list: set-type 
add 'set-type' to connect-list 
| set-type-list COMMA set-type 


add successive 'set-type'(s) to connect-list 


} 
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/* The DISCONNECT means: Disconnect the current record of the run unit */ 


/* from the set type occurrence that contains the record. z 
disconnect: DISCONNECT record-type FROM 


if (record-type’ record is not current record of run unit} 
perform error(3) 
return 

end-if 

else 
alloc and init new connect-list 

end-else 


) 


set-ty pe-list 


alloc and init ’disconnect’ node 
for (each set-type on connect-list) 
if (’record-type’ is not a member type record for ’set-type’) 
perform error(5) 
return 
end-if 
else 
alloc and init new abdl-str 
copy "IUPDATE ((TEMPLATE = ’record-type’) and 
(DBKEY = CIT.RUN-UNIT.dbkey)) 
(MEMBER. set-type = NULL)|" 
to abdl-str 
connect abdl-str to 'disconnect! node 
end-else 
end-for 
connect-list = NULL /* reset connect-list */ 


j 


perform-loop: PERFORM UNTIL bb EQ cc 
| END-PERFORM 


3 


bb: EOF 
| NOTFOUND 


3 


cc: YES 
| NO 


) 
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item-list: item-name 


{ 


put item-name on select-list 


| item-list COMMA item-name 


{ 


put successive item names on select-list 


} 


schema-name: IDENTIFIER 


, 


record-type: IDENTIFIER 


3 


set-type: IDENTIFIER 


3 


item-name: IDENTIFIER 


, 


item-value: IDENTIFIER 
| INTEGER 


) 
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proc error(err-code) 
/* This procedure prints error messages, causes data structures to */ 
/* be de-allocated, and causes proc yyerror to be executed. D 


case err-code of 
1: print("Error - must initialize ’record-type’ record-template") 


t2 


: print(" Error - 'data-item' not defined in 'record-type”") 

3: print("Error - ’record-type’ is not current record of run unit") 

4: print("Error - attempting to modify or store record without 
giving value of ’data-item’") 

5: print("Error - ’record-type’ record does not belong to 'set-type'") 

6: print("Error - record-types specified are not the same") 

7: print("Error - ’record-type’ is not current of ’set-type’") 

8: print("Error - ’record-type’ must be a member record of ’set-type’") 

end-case 

perform cleanup() /* free data structures */ 

perform yyerror() 


return 
end-error; 
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proc by-application(abdl-str) 


if (set-node nsn-insert —'a' ) /* insertion mode is automatic */ 
concat", <MEMBER.set-type,CIT.set-type.owner-dbkey>" to abdl-str 

end-if 

else /* insertion mode is manual */ 


concat", « MEMBER. set-type, NULL" to INSERT abdl-str 


end-else 


end-by-application; 


proc by-value(abdl-str) 


locate data-item node in schema for set-select node item-name 
in set-select node record1 
if (nan-dup-flag set) 
get owner record type of set-type from schema 
if (owner record type node not on move-list) or 
(data-item not on move-list) 
perform error(4) 
return 
end-if 
else 
if (set node nsn-insert = ’a’) /* automatic insertion */ 
get data-item value from move-list 
copy"[RETRIEVE((TEMPLATE = owner-record-type) and 
(item-name = '¡item-value”)) (DBKEY)|]" to abdl-str 
connect new retrieve request to store node 
concat",<MEMBER.set-type,***>" to INSERT abdl-str 
end-if 
else /* manual insertion */ 
concat", <MEMBER .set-type, NULL>" to INSERT abdl-str 
end-else 
end-else 


end-if /* nan-dup-flag */ 


end-by-value; 
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proc by-structural(abdl-str) 


locate data-item nose in schema for set-select node item-name 
in set-select node record] record-ty pe 
if (nan-dup-flag set) 
get record! name from set-select node for set-ty pe 
if ('record1! record template node not on move-list) or 
(data-item not on move-list) 
perform error(4) 
return 
end-1f 
else 
if (set-node nsn-insert — ’a’) /* automatic insertion * / 
get data-item value from move-list 
get record2 name from set-select node for set-t y pe 
copy"[RETRIEVE ((TEMPLATE = record2 name) and 
(item-name = item-value)) (DBKEY)" to abdl-str 
connect new retrieve request to store node 
concat", <MEMBER .set-type,***>" to INSERT abdl-str 
end-1f 
else /* manual insertion */ 
concat" <MEMBER .set-type, NULL>" to INSERT abdl-str 
end-else 
end-else 
end-if /* nan-dup-flag */ 


end-by-structural; 


proc by-default(abdl-str) 


print(" Warning - Attempting to store a record with no 
particular set selection given. Will assume 'BY 
APPLICATION") 
if (set-node nsn-insert = ’a’) /* automatic insertion */ 
concat" <MEMBER.set-type,CIT.set-ty pe.owner-dbkey>" 
to INSERT abdl-str 
end-if 
else /* manual insertion */ 
concat", <MEMBER.set-type, NULL>" to INSERT abdl-str 


end-else 


end-by-default; 
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proc erase-all(record-type,erase node) 
string member-type; 


for (each set-type in schema) 
if ('record-type' is owner type of set-type) 
member-ty pe — member type of set-type 
/* for RETRIEVE to get members of *set-type” */ 
alloc and init new abdl-str 
copy "'RETRIEVE(MEMBER.set-type = ***)(DBKEY) by DBKEY|" 
to abdl-str 
connect abdl-str to erase node 
/* delete member records */ 
alloc and init new abdl-str 
copy "¡DELETE((TEMPLATE = 'member-type”) and (DBKEY = ***))]" 
to abdl-str 
connect abdl-str to erase node 
/* erase descendants of member records */ 
erase-all(member-ty pe,erase node) 
end-if 
end-for 
return(erase node) 


end-erase-all 
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